log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: General: Who *wants* an Open Source RO?
 
  Who *wants* an Open Source RO?
  This is a long thread. Click here to view the threaded list.
 
GuestX Message #42507, posted by guestx at 07:52, 20/5/2003, in reply to message #42501
Member
Posts: 102
You originally said that you wanted a way to be able to write in the style of RISC OS WIMP applications.
That is true, and implementing (some of) the funtionality of OSLib using DirectFB was the approach I wanted to take to that.
I actually thought riscose was moving in this direction, albeit without a specific reliance on DirectFB. However, I don't see the point in doing direct framebuffer business unless you want to run the resulting operating environment on very limited hardware (like reasonably old Acorn machines).

You haven't addressed the concern of having more than one toolkit.
No, I haven't. I think one would be enough to be getting on with, and the rest can run on the X Server application I was talking about (and look alien).
Whilst the main UNIX desktop environments favour one toolkit over others, neither of them exclude the other toolkits. I think that sends an important message about such issues.

GTK may be nice, but it doesn't make for RISC OS' style. You'd be looking into a new toolkit, which is why I suggest that incremental porting won't work.
I don't agree with this entirely. The main toolkits have theming which can get the appearance quite close. As for the behaviour...

Well, starting from a normal GTK application, couldn't you:

* change it so it doesn't open a window on startup, just put an icon on the icon bar (and open the original startup window when select clicking the icon),
Even if you didn't want to modify the application or the toolkit, I can imagine that some tricks could be performed with window managers to capture windows. Or you could implement "panel applets" to more or less achieve what you want, especially with the various component automation mechanisms in various desktop environments.


* open files dropped on the icon bar as if they'd been chosen from a file->open dialog on a default new window
I'd like to see the main desktop environments work a bit harder on this, so that their file explorers actually work more closely with applications. However, you could probably add this functionality to those "panel applets".

* move menu items that affect the whole application to the icon bar menu (preferences, etc.)
Again, it would be interesting to experiment with "panel applets" and automation. You might need to track the application's development yourself and reimplement the menus, though.

* use drag and drop saving
This might well need toolkit extensions, unfortunately.

* respond to file open messages if the file type is supported by the application
Applications are typically opened in existing file explorers as a consequence of file open operations. Whether it opens a new instance of the application concerned quite often depends on how the application is developed and deployed, however.

* (trickier) pop up menus on middle button pushes, with selection of something under the pointer if nothing is already selected
Button configuration is easily achievable in the various desktop environments, but changing the nature of the pop-up menus would require work at the toolkit level to be most effective, I suppose.


... and so on?

I just don't know enough to write a new toolkit from scratch, but I'd have a better idea once I'd modified a few GTK apps.
Well, go for it! You don't need to apply for permission from the self-appointed "guardians" of the platform.


Besides, how do you think I'd convince people to use a brand new toolkit, anyway? An evolutionary approach is probably more likely to succeed.
Indeed.


One other RO - style adjustment I'd look into would be to lock window re-draws so that they happen seqentially and the most recently requested (by the user) first.
I think that the only reason why RISC OS seems more responsive in this respect is because the user is prevented from performing lots of asynchronous actions which could cause unfinished redrawing. Personally, I think that this adjustment would require a lot of work for a steadily decreasing reward, as hardware gets faster, latencies in various mainstream operating systems are improved, and so on.
  ^[ Log in to reply ]
 
Pages (2): |< < 2

The Icon Bar: General: Who *wants* an Open Source RO?