Jump to content
Visual Boy Advance-M

darktjm

Members
  • Content Count

    0
  • Joined

  • Last visited

Community Reputation

0 Neutral

About darktjm

  • Rank
    Newbie
  • Birthday 03/05/1969
  1. darktjm

    wxWindows port?

    Good luck. I've done all I could. I will no longer go on IRC or monitor/post on this forum. I will probably be removing my web page as well within a week. I don't want anything to do with the main devs of this project any more. I don't even remember why I chose this particular GB/GBA emulator to work with to begin with.
  2. darktjm

    wxWindows port?

    The more I play it, the more I patch it.. I have added 5 patches to the main bug (3302799) since my original posting, and one to the ffmpeg bug (3302797). These fix a few bugs and add mouse pointer blanking and ubuntu install support. I think I'll put off any further patching until it gets merged, though, if ever. Unless someone reports a serious bug, that is. I am a little concerned that nobody has tried this on a Mac, but at least it works for me on the only platform I care about. Also, I've placed Ubuntu 10.04LTS binaries on my site, since that's what was released last time. I also packaged the patches with an ebuild for gentoo users. I have not tested the ubuntu binaries other than "it installs" and "it runs" (and, to test the ffmpeg changes, "it records").
  3. darktjm

    wxWindows port?

    There are no known issues with 2.8.4 (May 2007). I did most of my testing with 2.8.12, though. 2.9.1 builds (even without 2.8 compatibility enabled), but has known issues (see the page linked above for the list). There are a few 2.8 widgets (e.g. the pickers) and many minor API changes that make 2.6 support difficult enough that I won't try. It might work with earlier 2.8 releases, though.
  4. darktjm

    wxWindows port?

    Hmm.. email notifications seem to be broken, since I missed most of the replies after my previous rant. Anyway, I'm sick of working on this thing, so I've gone ahead and posted my code to the tracker. Unfortunately, I posted the final patch (wxWidgets front end, 3302799) as a bug rather than a feature request, but if anyone cares, they can move it around. As to GTK being portable: I would agree that the SDL front end is portable, but the GTK front end is GTK. It's like saying the Windows GUI is portable because I can link against winelib on MacOSX and Linux. GTK has its own look and feel, and really doesn't work very well under Windows or MacOSX. The GTK front end is also missing quite a few features from the MFC front end. Look for darktjm-posted bugs (10 total) for the list. Each one has a patch attached. See http://darkalpha.homelinux.org/wxvbam/ for long-winded notes and win32/mac binaries. In summary: I don't think it was worth the effort, but what's done is done. Now I can go back to playing games and watching TV. In case it wasn't clear from the above: it works, and it does a lot of stuff the GTK interface can't. It still has a few bugs and missing features, though (see bug 3302799 for my todo list).
  5. darktjm

    wxWindows port?

    Maybe because I wanted to discuss things first? To see how others felt about it? Maybe because I thought this forum is supposed to be about GUI wishes? Maybe because I tend not to open issues unless I have a patch to go with it? Any of these reasons good enough for you? Or were you suggesting that I file a bug report against the GTK GUI about feature disparity? I don't think that fixing the GTK front end is the correct solution. GTK is only marginally cross-platform, so I doubt people will be satisfied with dropping win32 in favor of gtk. This means that feature disparity will always be an issue. By the way, thanks for responding to my question about the GTK port. I can't believe that you think the Windows front end and GTK front end have feature parity. The SDL and GTK front ends don't have feature parity either, by the way. I suggest you look at the actual features provided once to see what I mean. Just scroll through the menus/command-line/config-file options; it doesn't take a lot of time. If you're stuck in Linux, like me, you can use Wine to evaluate the Windows front end. And no, I will not open a bug report for that. If you care enough to fix it, then you care enough to report it (and, as far as I'm concerned, vice-versa). It seems to me like you don't want me to continue what I'm doing. If so, that's fine. I'll just crawl back into my lair and do it for myself. It's not like I'm asking for anything in return, anyway, except perhaps future consideration for Linux users.
  6. darktjm

    wxWindows port?

    What do you mean by "now"? The latest SVN (1010) looks pretty much the same as the last time I looked. Has someone implemented the missing features I listed above in an alternate branch, maybe? Or not checked it in yet? Or am I looking at the wrong SVN? Regardless, I will press on, even if it's just for my own amusement. Having multiple front ends to maintain will lead to feature disparity again.
  7. darktjm

    wxWindows port?

    I could, I suppose. I have somehow managed to avoid IRC since its inception (chaotic communication bothers me for some reason, and I'm not much of a talker, anyway), but I think I have pidgin correctly logged into #vba-m at irc.freenode.net. I would use the "chat" link in the form and main page, but it's broken for me (java security exception). As with any real-time communication, we would now need to agree on a time. I'll just remain logged in for now.
  8. darktjm

    wxWindows port?

    The licensing probably doesn't matter. I was under the impression that there are still some embedded uses that required commercial licenses, but then again, supporting PDAs is probably not a high priority, and I'm probably wrong. Really the main gripe I have with qt has always been that I don't care for the idea of a c++ preprocessor. It's a personal preference that's easily overcome. If the Qt route is preferred, I'll abandon my wxWindows work in progress and go with it, regardless of my opinions on the toolkit itself. However, if the concern is merely that I am putting more effort into it than necessary, then I'd prefer to continue with wxWindows. That brings me to another issue with the Qt front end: where is it? It's not in SVN, at least that I can find. Not finding it is part of the reason I believe it's been permanently abandoned. The other reason is that the sticky thread on this forum has no new posts for years.
  9. darktjm

    wxWindows port?

    Currently, the Windows front end has a number of features not present on the other front ends. My wish is to see any non-Windows-specific features on the other platforms, as well. To that end, there should be at least a platform-independent GUI front end. It seems that a Qt version was worked on a few years ago, and then abandoned. I instead propose a wxWidgets (+other) version. For my own amusement, I have already started implementing some of this. My plan is to just copy the gtk and windows GUIs and all three front ends' features as much as possible, without implementing any new features. On the other hand, even if I get something working, will this just be a one man operation? I mean, is there even any desire on the part of currently active developers to switch to something completely different, and end development on the other three front ends (or maybe just the gtk and win32 ones, since the SDL front end is presumably already cross-platform, and may be more desirable than wxwidgets due to smaller size)? I have no intention of forking/maintaining this in the long term. I am open to suggestions on what libraries to use. I chose wxWidgets for several reasons, which I am happy to list if alternatives are proposed. Qt in particular is something I don't care for due to the weird licensing and other issues. That doesn't mean I won't use it if that's what the primary vba-m developers think I should use, though. Here's a current list of features I would like to see cross-platform, in order of importance: - link - A/V recording - minor changes in state save/restore - aspect ratio - debugging tools Some of this may require major effort and/or other library dependencies. For example, link would need to use SFML, most likely, and A/V recording some other method (ffmpeg exec was suggested, although I would prefer using libavcodec if possible to avoid platform-specific piping issues).
×