GCL Plans
DISCLAIMER: this text is lengthy - if yor not interested in GUI programming or API design, you should stop reading now.
This year I held at YAPC::EU, italian and german Perl workshop a lightning talk about an idea - complete vaporware, but an idea of a better world where Apps are a breeze to write. But this will maybe change since I'm much inclined to do it, it just will take some time. The problem: GUI programming sucks badly. Its way to complex and too much to type, especially in Wx. There are some techniques to ease the pain (a talk about that I will submit to this years YAPC) but we need a radical shift here. Prima is a step in the right direction but Rebol (see my YAPC::EU talk from 2 years ago - slides) is the way to go here. Its a DSL that takes the least amoun of characters possible, yet very clear and readable. We need a DSL in Perl for that too (DSL in the ruby, not in perl 6 sense). But as the FreeTuit (which I got sources from Eric Wilhelm++) experiment shows, its too hard to build all at once. So I will produce first some smaller modules that are useful on there own and then combine them to a whole. Tie::Wx::Widget was the first tiny step for that.
The second important decision is to do it like RoR - develop a framework with an app that uses it. And the app is of course the best editor in the world: Kephra. I currently reboot the project, meaning rewrite it from scratch. Its still a source code viewer, but already has 4-5 features the old Kephra never was able to deliver. As soon it will be usable as an editor, you will read it here in big letters.
But instead of start minimal and do constant rewrite I first designed the architecture of namespaces, employing perl to check is the logic of the modules is formal sane. Another feature of my writing style is not just write a feature after another but to develope modules to a degree a API and a inner logic is visible and write always groups of features at once that have to designed together. Thishow I wrote these days Kephra::App::Panel which maybe ends up as one of the first of the to be released separate modules. It started as a helper function, simple to put a panel unter a widget, just to place it on a notebook or alike (I know that is not necessary - the whole reason will come later). But its now expanded to a class which is derived from Wx::Panel and which makes it easy to insert some widgets on it without to wrestle with a sizer. In the next version you will be even give callbacks where you can say "just put it after the widget which title matches that regex". And its now only for vertical linear design but I plan for rows too. Its so much less code and all the reparenting goes automatically and some things more. its almost like going from old school OOP to Moose. And its really just the beginning. You just give a list of widgets to the panel and its on it in that order. If you just put a backslash before the widget, make it a reference, you tell it to make a place dominant widget which will eat up the rest of the space. And if there is one widget in the list which has a extra wish, eg border - you put it in curly braces, insert a border => $px and there you go. Your own code will become much more readable. The next stop will be a splitter that holds its children and also manages all the reparenting stuff and the whole hassle. Also the 3 days work to get a AUI::Notebook that actually knows its visual order of the tabs (even when they dragged by mouse) I should package in a CPAN module.
Yes this is a sort of cry for help or for people with similar ideas to join forces. And no its not doable with Padre, since they have an architecture that doesn't allow and desire what I plan for. But thats a topic for another rampage here on this site my dear readers.
Kephra, Articles, Books, Perl, Programming
It would be awesome if you can do this.
ps. There was no reason to mention Padre in this. I don't think anyone in their right mind will expect you to abandon your project. Really. Just do it for your fun, the rest will work out.
I was a bit excited about the idea of having a GUI library with an easy-to-use API, but when i looked at the code i saw use of globals which made me sad. :(
Please think a bit further in my favour. In this Module which is still in builtup mode, there is exactly one variable which isn't a global but what you mean is it defies the pure OOP logic. its a coderef to a Kephra helper function, which of course get refactured away if I release it as a module.
It really isn't your problem but mine. I was asked this question e.g. on german perl workshop quite often (and didn't liked it either much) so I assumed that people here would come up with it too and i wanted to dry this up from the start.
I also came up because i initially wanted to mention my plan to take over the Wx::Perl::Dialog which came sorta out of padre and why i decided that it's wiser to make first a panel based module. In this reasoning the different directions of the project play a role but I ditched thead almost completely so just this fossil remained for the reason stated above.
My whole post is about clarify goals also to myself. Im glad that there is padre because we need such a type of editor and if it would just about me not ditching my project i would maby done this, because you have much more devs.
The same people who ask you "Why not Padre?" probably asked me 3 years ago "Why not Kephra?".
IMHO it's a good opportunity to explain things.
Some of those people have probably implemented at least one templating system of their own.
Or they plan to :)
We end of lifed Wx::Perl::Dialog because it didn't work very well. It greatly limited the structure of the dialogs you can create, and in our version it also had fixed sizing (which sucked).
I'm convinced that the wxFormBuilder method with a GUI designed is better and more scalable (and it is much easier to tweak other people's initial designs).
That's nothing against your approach, just be mindful of the usability of changing layouts of other people's code.
I dont have the feeling i get the sense of your last post.
As I said in these lightning talks mentioned, FBP is one aproach, which satisfy the need for visual feedback as some easy of learning the Wx API. But on the other side WxFormbuilder is Generations behind of what Microsoft offers (DND widgets pixel-wise). So I choose instead to compete with that, i do it in a different way which also is more the natural way of the hacker: to use its editor and and his imagination. By doing the textual API so simple (and a good editor can provide aid with even that) and the F5 butten which can run the program (and let you see your result now) you can not only create your gui easily, but also change and reuse gui parts more easy than with the builder.
I learned a lot from rebol. Instead of having XRC or FBP which is still an outer technology, gcl is a bunch of function calls, read native perl which creates ordinary Wx-objects. Not having any technology barrier is at least to me the most elegant solution. But admitted I'm not nearly as far as FBP is today.