Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Hans_ on December 14, 2007, 07:50:05 PM
-
I was discussing wxWidgets over on AW.net (http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=24963&forum=15) and discovered that Abalaban and Yomgui started a port (well, implementation really) of wxWidgets for Amiga OS (OS4, MOS and 68k). Unfortunately it stagnated as it's a pretty big task.
My interest lies in wanting to write cross-platform code. WxWidgets uses the native widgets of whichever target OS it's on, resulting in a consistent look-and-feel, unlike other toolkits (e.g., look at GTK ports to windows, it doesn't look like a windows program).
Seeing as amiga.org has more 68k, AROS & MOS users than AW.net, I thought I'd ask here if any other developers are interested in continuing the wxWidgets-aos port. Ideally we'd have AOS4, MOS, AROS & AOS-68k developers working on this, so that each OS' build remains up to date. The sourceforge page is here (http://sourceforge.net/projects/wxwidget-aos/).
Abalaban and Yomgui got wxBase partially done (don't ask me how complete), so there's still much work to be done.
Hans
-
Nobody's interested? I had thought that within the larger Amiga community there would be at least a few people interested in this.
Hans
-
Hans_ wrote:
Nobody's interested?
I guess not. :-(
-
I guess not. :-(
I'm interested, but in the completed program. I couldn't code to save my own life so I'm of not much use there :-)
-
Hans_ wrote:
WxWidgets uses the native widgets of whichever target OS it's on, resulting in a consistent look-and-feel, unlike
That is all true, but it doesn't really work that way in practice. Unfortunately. (for example aMule on the Mac has some very serious visual anomalies and performance issues when scrolling lists, etc).
We used wxWidgets in my last project and it was not fun. A lot of pain. Overall it's not as bad as other things, but it's got lots of gaping holes and inconsistent behaviour and some really subtle bugs.
Couple of things to consider as well:
I wouldn't necessarily call it bloated, but it's big-ish. Also, not so many applications are written with it in mind vs QT or GTK*, which might make those better port targets. Lastly, it's all C++ so it'll need a capable enough compiler (thinking 68k here).
It's probably worth having anyways... just not so excited about it's existance.
-
If wxWidgets port for AOS were completed I would be very pleased. At least then I could port also my personal projects for miggy and use miggy as a dev-platform. If I had more time to spare I might be also interested in porting wx.
wxWidget is indeed very handy GUI-toolkit but not so newbie friendly or fully complete. IMHO if we look for free, multiplatform and feature rich toolkit then wx is it.
-
da9000 wrote:
That is all true, but it doesn't really work that way in practice. Unfortunately. (for example aMule on the Mac has some very serious visual anomalies and performance issues when scrolling lists, etc).
We used wxWidgets in my last project and it was not fun. A lot of pain. Overall it's not as bad as other things, but it's got lots of gaping holes and inconsistent behaviour and some really subtle bugs.
How long ago was that? And which version of wxWidgets were you using. I'm sure that there are issues, however, it's more consistent than some of the other GUI toolkits out there.
I wouldn't necessarily call it bloated, but it's big-ish. Also, not so many applications are written with it in mind vs QT or GTK*, which might make those better port targets. Lastly, it's all C++ so it'll need a capable enough compiler (thinking 68k here).
I'm not interested in wxWidgets for the purpose of porting more Linux apps over; I don't care for ports. I'm looking for something that I can use to write new software so that I can easily port it between multiple platform. I don't like GTK or Qt, and wouldn't consider using either of them.
The wxWidgets-aos project compiles on 68k via GCC, so it being C++ is not an issue.
Every toolkit has its quirks; wxWidgets' documentation mentions that certain features are Windows or Mac only. However, wxWidgets looks fairly easy to use. Someone else told me that it was the easiest to use GUI system that he'd tried; better than both Reaction and MUI.
As for the size; it is biggish, but it includes a lot on top of the GUI stuff. It is broken up into modules, so you only need to include the ones that you need. The size is something I'm prepared to live with because I don't have the time to build completely separate GUIs for each platform. That sounds like a support nightmare. The first thing that I'd probably do, would be to write an abstraction layer that uses native widgets on each platform via a common API. I'd pretty much be making my own wxWidgets equivalent. Why not use something that's already there?
Hans
-
DrValkyer wrote:
If wxWidgets port for AOS were completed I would be very pleased. At least then I could port also my personal projects for miggy and use miggy as a dev-platform. If I had more time to spare I might be also interested in porting wx.
Any help with the port is welcome. All of those involved at the moment have other projects running and can only devote a little time. The link to the project is in the first post in this thread.
Hans
-
I just had a look at the sourceforge page, and what's there looks like a good base to build on, for people familiar with C++ and CVS. Unfortunately, all my Amiga programming has been with assembly, Modula-2, and C, using RCS, so I don't think I can be much help for now.
-
Hans_ wrote:
How long ago was that? And which version of wxWidgets were you using.
As of the first quarter of 2007. At the time we were using the latest version released (primarily Windows platform), but I can't recall the number right now.
Hans_ wrote:
I'm not interested in wxWidgets for the purpose of porting more Linux apps over; I don't care for ports. I'm looking for something that I can use to write new software so that I can easily port it between multiple platform. I don't like GTK or Qt, and wouldn't consider using either of them.
Aha, well now that your goals are stated clearly, I understand your logic. Yes, wxWidgets makes most sense compared to the other two (although the latest QT is technologically more advanced, albeit much harder to port), especially in light of the lack of another good and readily available choice.
Hans_ wrote:
The wxWidgets-aos project compiles on 68k via GCC, so it being C++ is not an issue.
Compiles is one thing, runs properly (aka the compiler outputs the right code for what it was asked to compile) is another. I only brought up this matter since the state of the existing project was unknown to me, and this could have been a big issue. If it also runs properly, then that's good news indeed. That makes it even easier.
Hans_ wrote:
Every toolkit has its quirks... Someone else told me that it was the easiest to use GUI system that he'd tried
Yes, indeed each can have its own issues. Although personally I found wxWidgets obtuse (even in naming conventions, like what's a frame or a window), but then again I was comparing with Cocoa...
Hans_ wrote:
As for the size; it is biggish, but...The size is something I'm prepared to live with because I don't have the time to build completely separate GUIs for each platform... Why not use something that's already there?
Your logic is... logical :-) I only brought up the size matter, not in the sense of bloat, but more of work needed to do the porting (I hadn't checked the source to see how portable it would be for the Amiga's case, so I used generic intuition, since usually bigger is more complex and thus usually harder, no?) But compared to the other choices it's smaller, and like you verified it's already partially working, so in this case and unless there's nothing smaller and more viable, its size is 'good enough'. So you look set to go.
On a personal note, I'd love to work on porting GNUstep to the Amiga one day. "Nuttin' like it!"
-
da9000 wrote:
Your logic is... logical :-) I only brought up the size matter, not in the sense of bloat, but more of work needed to do the porting (I hadn't checked the source to see how portable it would be for the Amiga's case, so I used generic intuition, since usually bigger is more complex and thus usually harder, no?) But compared to the other choices it's smaller, and like you verified it's already partially working, so in this case and unless there's nothing smaller and more viable, its size is 'good enough'. So you look set to go.
The port is in its very early stages. It's a partial implementation of the base module, so no GUI stuff yet. It is a big project so I was hoping that more people would be interested in helping out. Fortunately it looks like they've used a pretty good structure and there are several different OSes that can be used as examples. The PalmOS port looks like its in its early stages so it could make a good starting point for the core module (not too much code to rip out to make the starting skeleton code.
Yes, indeed each can have its own issues. Although personally I found wxWidgets obtuse (even in naming conventions, like what's a frame or a window), but then again I was comparing with Cocoa...
Yes their use of wxWindow as base-class for all visible GUI elements is weird. I wonder if that's an artifact of whatever system they started on. I've seen multiple systems or RAD tools call windows frames, which I think is silly.
On a personal note, I'd love to work on porting GNUstep to the Amiga one day. "Nuttin' like it!"
I had a quick look at it s website but I'm not completely sure what features it has. The demo did make it look easy to use though. I only shuddered when they opened up vim as editor. ;-)
Hans
-
Hans_ wrote:
The port is in its very early stages. It's a partial implementation of the base module, so no GUI stuff yet. It is a big project so I was hoping that more people would be interested in helping out. Fortunately it looks like they've used a pretty good structure and there are several different OSes that can be used as examples. The PalmOS port looks like its in its early stages so it could make a good starting point for the core module (not too much code to rip out to make the starting skeleton code.
Aha, thanks for the status update. It seems that it'll be a good start, especially if there's some possibility from borrowing from the PalmOS port.
Hans_ wrote:
Yes their use of wxWindow as base-class for all visible GUI elements is weird. I wonder if that's an artifact of whatever system they started on. I've seen multiple systems or RAD tools call windows frames, which I think is silly.
Agreed 100%. Perhaps it is a vestige of time, as you say.
Hans_ wrote:
I had a quick look at it s website but I'm not completely sure what features it has. The demo did make it look easy to use though. I only shuddered when they opened up vim as editor. ;-)
Hahaha, understandable! I'm no vi fan either, probably because my first editor discovery was pico when I made my switch to Unix, but I'm a huge fan of Bill Joy (http://en.wikipedia.org/wiki/Bill_Joy), creator extraordineur of vi, BSD, etc. As some of us say: "the other Bill". Other having a positive connotation in this case :-)
As for features, I'm not so sure what you mean, but all the info you need can be found on the web site. Also check out the wikipedia article (http://en.wikipedia.org/wiki/GNUstep) under the "Capabilities" section, and the links section.
-
Could be an interesting project I guess. C++ is my primary language so it shouldn't be problematic.
Still there are a couple of things holding me back:
1) I have no previous experience with wxWidgets; and
2) I'd never even dream on working on a project of this scale alone. Should probably be at least 3 active developers, since it'd be a hobby project.
-
Oh, btw: Emacs is the ultimate Unix editor :-D
-
Caius wrote:
Oh, btw: Emacs is the ultimate Unix editor :-D
Wikipedia begs to differ:
vi became the de facto standard Unix editor and a nearly undisputed hacker favorite outside of MIT until the rise of Emacs after about 1984. As of 2007 either vi or one of its clones can still be found on nearly all installations of Unix. The Single UNIX Specification specifies vi, so any system conforming to the Single UNIX Specification will have vi.
vi is still widely used by users of Unix variants. About half the respondents in a 1991 USENET poll preferred vi.[1] It starts up faster than the bulkier versions of Emacs and uses less memory. Consequently, even some Emacs fans will resort to it as a mail editor and for small editing jobs. In 1999, Tim O'Reilly, founder of the eponymous computer book publisher, stated that his company sold more copies of its vi book than its emacs book.[3]
BTW, I'm no fan of either (Boxer, an PC/MS-DOS editor is my favorite - could do column marking/blocking/selections!! And had awesome macro functionality), nor do I want to start a religious war, but thought I'd point out the statistical evidence (O'Reilly's numbers, etc) :-)
-
Just because something is widely used doesn't make it "best". Just as with anything else, it's a matter of personal taste. Nothing else really matters. Hence the smiley in my comment.
-
But back on topic.
Surely there's got to be better alternatives than wxWidgets? With "better" I really mean light-weight. I can only imagine how it would work on a stock A1200. Would most likely be slow, and take a lot of memory. Note that I'm only assuming here. I don't actually know this for sure. But I think that any cross-platform GUI library, aimed at including classic Amiga, should run well on a stock A1200.
-
Hence my smiley after "statistical evidence". I agree with your definition of best.
Caius wrote:
Surely there's got to be better alternatives than wxWidgets? With "better" I really mean light-weight. I can only imagine how it would work on a stock A1200. Would most likely be slow, and take a lot of memory. Note that I'm only assuming here. I don't actually know this for sure. But I think that any cross-platform GUI library, aimed at including classic Amiga, should run well on a stock A1200.
I also think it won't be so lightweight, but then again, it's more popular than many other toolkits and on more platforms, which was a concern that Hans had.
As for target machine, I don't know if a stock A1200 should be the base (maybe too low? how about RAM?). I guess it depends on what the authors have in mind.
EDIT:
I've not looked at it in depth, but I recall hearing of this:
http://www.microwindows.org/
And more:
http://en.wikipedia.org/wiki/Windowing_system
-
Caius wrote:
Could be an interesting project I guess. C++ is my primary language so it shouldn't be problematic.
Still there are a couple of things holding me back:
1) I have no previous experience with wxWidgets; and
2) I'd never even dream on working on a project of this scale alone. Should probably be at least 3 active developers, since it'd be a hobby project.
We currently have 5 people listed on the sourceforge page (http://sourceforge.net/projects/wxwidget-aos/).
Hans
-
Caius wrote:
But back on topic.
Surely there's got to be better alternatives than wxWidgets? With "better" I really mean light-weight. I can only imagine how it would work on a stock A1200. Would most likely be slow, and take a lot of memory. Note that I'm only assuming here. I don't actually know this for sure. But I think that any cross-platform GUI library, aimed at including classic Amiga, should run well on a stock A1200.
AFAIK it's the only cross-platform GUI toolkit that uses native widgets. How fast/slow it is depends on how it's event handling is implemented. Also, it's fairly modular so if their's some component that you don't need, don't add it to you project.
We'll have to see how resource hungry it is. I doubt that you're going to find any cross-platform GUI toolkit that's fast on a stock A1200. Even MUI is sluggish on that machine. I was going to say that there are PalmOS and Windows CE wxWidgets ports on the way, but the average PDA has more memory and a much faster CPU than a stock A1200.
Hans
-
Yes, I've been to the SourceForge page. I've got a few
points to make:
1) I've browsed the CVS repository. Apart from a couple of
minor updates to compile under OS4, there hasn't been any
activity for two years. That's why I said active developers.
2) It would be fun to help out in such a project, but as
I've mentioned I have no previous experience with wxWidgets.
Therefore the project needs to be lead by someone who knows
the code well, who can delegate tasks to the other
developers. This person must, obviously, be highly active.
3) The project needs to be kept in sync with the main
wxWidgets project. wxWidgets v3 is approaching, and there
is no point in making a port that is quickly outdated.
Therefore the CVS repository must be updated/synchronised
with the main wxWidgets project on a regular basis.
A little more work, yes, but otherwise there would be no
point in doing this at all.
In other words, I'm waiting for someone to assume
leadership of this project. And no, it can't be me for the
reason stated above.
(Also, having no access to OS4-capable hardware, I could
only work on the AmigaOS 3.x code).
So that's basically where I stand.
-
Oh, and I've been reading up a little on wxWidgets. I don't
think it is as heavy as I thought. Seems to be implemented
as a thin wrapper around native code. In other words, a
front end to whatever GUI API it's implemented on. The
overhead of such wrappers are generally low. I've written
such wrappers myself (MySQL, PostgreSQL and SQLite), and
it performed just as well as using the C APIs directly.
Which raises another question. Best performance would
probably be gained from implementing directly on top of
intuition.library. However, the port would most likely
be developed much faster if implemented via ReAction or
MUI. Both of these are available on OS4, yes?
-
Caius wrote:
Yes, I've been to the SourceForge page. I've got a few
points to make:
1) I've browsed the CVS repository. Apart from a couple of
minor updates to compile under OS4, there hasn't been any
activity for two years. That's why I said active developers.
Yes, that was me. The original two developers stopped working on it a few years ago because no-one else was interested. As you noticed, it's a big project.
2) It would be fun to help out in such a project, but as
I've mentioned I have no previous experience with wxWidgets.
Therefore the project needs to be lead by someone who knows
the code well, who can delegate tasks to the other
developers. This person must, obviously, be highly active.
Unfortunately, I'm only just starting to learn the wxWidgets API and the original developers are really busy with other projects.
3) The project needs to be kept in sync with the main
wxWidgets project. wxWidgets v3 is approaching, and there
is no point in making a port that is quickly outdated.
Therefore the CVS repository must be updated/synchronised
with the main wxWidgets project on a regular basis.
A little more work, yes, but otherwise there would be no
point in doing this at all.
I've been meaning to have a go at doing this, but haven't had any time.
In other words, I'm waiting for someone to assume
leadership of this project. And no, it can't be me for the
reason stated above.
(Also, having no access to OS4-capable hardware, I could
only work on the AmigaOS 3.x code).
So that's basically where I stand.
Understood. The good thing is that most AmigaOS 3.x code should work on the other systems too. I obviously can't do anything for MorphOS, but I'm sure that someone with MorphOS could at least adapt my code for the MorphOS version.
Personally, I can't take the lead in this project either, but I am going to work on small pieces from time to time.
Hans
-
Caius wrote:
Oh, and I've been reading up a little on wxWidgets. I don't
think it is as heavy as I thought. Seems to be implemented
as a thin wrapper around native code. In other words, a
front end to whatever GUI API it's implemented on. The
overhead of such wrappers are generally low. I've written
such wrappers myself (MySQL, PostgreSQL and SQLite), and
it performed just as well as using the C APIs directly.
Which raises another question. Best performance would
probably be gained from implementing directly on top of
intuition.library. However, the port would most likely
be developed much faster if implemented via ReAction or
MUI. Both of these are available on OS4, yes?
Yes OS4 has both. I'm not sure if MorpOS has Reaction (AROS doesn't) so MUI would probably be the way to go. WxWidgets also has its own version of all widgets (the wxUniversal module) which would be a good intermediate step before wrapping Reaction/MUI.
Hans