Yes, it's a lot of work. Besides my general interest for GUI frameworks, the second reason to start Xrw was my dissatisfaction with GTK# (not up-to-date, no reflection) and GTK (no modern/highly aggregated controls).
I'm sure - the 'near future' focus for Xrw will be MVVM and XAML. This is an objective, that is unrealistic for GTK#/GTK (because the latest Mono/.Net platform features must be applied and GTK is C). I can't estimate how much the Mono community stick to GTK#.
Because nobody cares for memory consumtion or CPU load today, XAML seems to be a real cool thing (now i can define a GUI via XML - and i would never return to program a GUI)!!!
With this aspect in mind: Would you renew your suggestion?
1. I'm totally cool with your interest in GUI frameworks I also love GUI frameworks. I even did two a while back (c++/win32). Speaking from experience, not sure this is the way to go (of course, this is my biased and totally personal opinion)
2. I'm not very sold on XAML - speaking again from experience, since one of the projects I'm involved in uses XAML big time. I'm totally for MVVM, but the VS editor sucks big big time, and haven't found a decent one.
3. Having said that, if the XAML does not match the one from WPF (so that the code would not be portable), not sure I would be inclined to use your framework.
4. In the near-to-medium future, I don't see myself ever wanting to program for X11-only. I want an awesome GUI form editor (which VS/WinForms totally has) - and looks like MonoDevelop has something rather decent. I would be interested to port my project (logwizard) to mono, but to develop a new UI from scratch - never.
5. So long story short, my interest in mono is a bit biased - I want to port c# projects as easy as possible. Which is why I think mono could certainly use developers like you.
6. About my original suggestion: if you could make something that is portable (Windows/Linux), I can certainly understand the appeal.
6a. If you decide to port WPF common controls to Linux, that would be deadly awesome - but again, a HUUUGE amount of work.
6b. If you decide to go with your own controls, you will have a much less user base. My take on this is that if you have a small user base, at some point, you will give up on it - since the work will outweigh the benefits big time.
thanks for your reply! This conversation helps a lot to think over where i am and where i want to go (with Xrw).
1. The question i have to answer for myself sooner or later is - shall i spend as much time for a framework (not an application)? At the moment it's still a lot of fun to enhance Xrw - but sometime the fun might turn into labour to close the holes (printing system and GUI editor).
2. XAML has a lot of pitfalls, but it convinced me the moment i compared the number of lines necessary to design a GUI. OK - if you design the GUI with an GUI editor (no matter whether Windows.Forms, WPF or GLADE) it doesn't matter.
3. Currently the XAML dialect of Xrw is almost 100% compatible - for all terms, that are supported. Take a look at my Code Project XAML articles, if you haven't already.
4. That is my point of view too, X11/Mono isn't interesting enough by itself. Instead it is very interesting for authors to provide their Windows application with very little effort for X11 as well.
5. I'll think it over.
6a. This is the way the framework should be advanced, i think.
6b. Absolutely. But it's not as easy as it was with Win32. WPF is based on DirectX. X11 has great support for OpenGL. Both require not only to implement the controls, but they require to implement the window manager and event queue as well. Even more HUUUGE amount of work.
1. Exactly. The thing is that the framework will be such a huge task, and it's very likely that at the beginning, most apps will run into some sort of trouble, which you will need to fix ASAP.
2. Agreed, once you have a GUI editor, you're good - which I always *ALWAYS* prefer. To me, in the 21st century, this is a requirement. Writing the GUI myself, line by line, that's like going back to stone edge. I just won't do it.
3. That sounds awesome!
4. Yes, and basically porting a WinForms using your lib does not work. I don't mean that as any offense, it's just what it is.
6b. I certainly wish you the best of luck! Basically, this is an insane amount of work. And lets not forget styles, triggers and such. I've seen some insane things done in WPF, and having that ported to X11 would prove pretty amazing.
Especially for answer 2. The WPF GUI editor of Visual Studio (including 2013) is bad - espcially the property editor, from my point of view. I prefer to create and place controls via WPF GUI editor and to configure them via XAML code. This makes it dispensable.
But this must not necessarily be the mainstream point of view...
I've already mentioned, that i use a specific sequence of tasks to produce suitable results with Visual Studio's WPF designer (becaus of the property editor's poor cacabilities).
And the alternative, Expression Blend, produces in most cases XAML code, that is much more complex than necessary - just to fit all imaginable needs.
One could think: It's time for just another WPF designer.
Not sure about library quality, but article is horrible. Is it your first publication in Inet?
Every publication should have PURPOSE. Hardly we met here to discuss in which version you got Pipette icon! *sorry for irony*
Skip all that deep-technical sh*t - most of us will USE library, not improve! And your presentation should concentrate on usage aspect, providing only necessary code to illustrate unobvious stuff (everything else we get from examples).
I like you have good screenshots, but again don't try to impress us with "file selection dialog" - we can see it from docs, but in article it's unnecessary.
Anyway even a try to create such library is a good exercise! Good luck in professional grow.
thank you - even if this is the first scathing criticism i got about my article(s). (The first thing i did is visiting your profile to estimate your opinion. Amazing negative reputation values...)
But nevertheless, i'll take your concerns seriously! This article did gow version by version and came unhandily very quick. With version 0.3 i split it into multiple articles. To do this was a suggestion from a feedback, i didn't feel very comfortable with that but i had no better idea.
The articles continued to grow and are unhandily again now. I have been thinking how to avoid that - without result so far. But now your feedback gave me an idea how to go on with the next article version. I'll outsource all the *boring API description* and concentrate the articles on: Tips, tricks and mastered challenges; Pitfalls and how to avoid them; Lessons learned using the underlaying technologies.
Because of its size, I haven't gone through the entire article. You only can best judge the size according to the content/topic you cover in each part. The only suggestion I can give is split it in such a way that the user will not loose interest while going through any part of the series.