Re: Browser Switchboard - use any browser as the default
 

I'll say "yes" to having "Web" bring up the default browser, because:

• In Windows (XP), I am able to change what browser shows up for the "Internet" entry in the Start Menu. (That said, this is a setting not determined by the choice of default browser.)
• Fremantle, by default, has "Web" as the first item in the menu, so I guess it'd be convenient for users to be able to fire up their browser of choice quickly.

Re: Browser Switchboard - use any browser as the default
 

This was a great read.

Here's my suggestion to remove confusion about what browser is associated with what link:

Overlay a small icon (or not, in the case of microb) at the bottom-right corner of the globe that represents the actual browser for that link. If you're forcing people to reboot after changing the default browser, this should be picked up nicely. And instead of renaming Icon: entries in .desktop files, for instance, just actually overwrite the actual .png files.

Then you could start having 3 or more browsers by centrally configuring them as:

browser (default)
Actual-Name: Tear
Label-Name: Web
browser2
Actual-Name: microb
Label-Name: microb
browser3
Actual-Name: Midori
Label-Name: Midori
...

Re: Browser Switchboard - use any browser as the default
 

I agree with this point of view. :)

Re: Browser Switchboard - use any browser as the default
 

Interesting idea -- but a reboot shouldn't be necessary to change the default browser (it should take effect the moment you hit OK in the UI). We'd also need to grow some image-processing code. I might take a look at this post-3.2, and patches are of course welcome.

It can't be that simple if we want to deal with package upgrades and SSUs correctly. I think you'd dpkg-divert the original icons out of the way, install symlinks to a location the user can write to (so that we don't need to gain root privileges when we change the default browser), and write the modified icons there.

I don't think Browser Switchboard needs to be involved with this, since all the other browsers will be installing their own menu entries already. We just need to control which is the default browser.

Re: Browser Switchboard - use any browser as the default
 

Oh, duh, you only care about the default browser. I think I wrote that early in the morning.

Believe it or not, scaling and overlaying an image on to another image is one function call, and qwerty12 knows a little about it. :) That's probably why I thought of it.

What you guys are doing interests me because I've been hacking on some mediaplayer stuff, and I might want to do something similar.

Re: Browser Switchboard - use any browser as the default
 

Was that the discussion on how to duplicate Diablo MicroB's favicons in the task list?

I got a proposal via PM for doing something similar for mail clients too a while back. From a UI standpoint, it'd make a lot of sense to unify all of these, but from a backend perspective (at least in my opinion) it doesn't work that well. Still, I imagine some degree of integration and/or code sharing would be possible -- if you do go ahead with this, do let me know!

Re: Browser Switchboard - use any browser as the default
 

Yes it was. The allusive solution had been in limbo for months; I thought for sure Nokia was hiding it somewhere in their browser code. Then, out of nowhere, qwerty12 found the one-line standard GTK call. Standard! Right in front of my nose! Crazy. He's gold.

If you feel like it, I wouldn't mind a short synopsis why you think so.

Be happy to, thanks. I'm not sure if you've looked at the MAFW stuff, but it's interesting how the pieces talk to each other asynchronously via the dbus. There are 6 daemons running if you include the tracker. And that doesn't include the mediaplayer itself which has something always running.

Re: Browser Switchboard - use any browser as the default
 

There are a few general (and one specific) concerns I have about merging non-browser-related default program selection functionality into browser-switchboard:

• Complexity -- we go from building a program to handle one D-Bus interface with one clearly defined purpose and essentially a single method (launch a browser) to handling multiple D-Bus interfaces that do quite different things. Not impossible, perhaps not even hard depending on what the other functions involve, but not as straightforward as now.
• Packaging complexity -- we have to replace more files that shipped with the system, and if we screw up in one place (as I did several times when developing the packaging for Browser Switchboard!), we can now potentially break more than one function.
• Code size -- with continuous mode off (the default), performance should be (I haven't measured) almost completely determined by startup time, which in many cases is going to be completely determined by how long it takes to load the code from stable storage.
• One problem specific to launching MicroB: currently, we don't go back into the event loop to process more D-Bus messages until after MicroB finishes, which could take a very long time. This is fine if we only handle the osso_browser interfaces (we let MicroB handle those while it's open), but we'd have to remove this restriction if we don't want handling of mail/media requests to stop while MicroB is open, and doing so would make already complex code even worse.

On the other hand, I see only one minor advantage to handling all of these functions in one program:

• Memory footprint -- one small program dispatching two or three different services will save a few hundred KB over two or three small programs each dispatching one service.

With that in mind, I think it'd be best to have different backend programs for each interface we want to handle, each of which ships in a different package. The programs could share a configuration UI and possibly also code (where that makes sense). I don't know whether those different programs belong in the same codebase or in separate projects.

As usual, anyone is welcome to prove me right or wrong with patches :)

Re: Browser Switchboard - use any browser as the default
 

The thing is, however, Browser Switchboard doesn't require you to reboot to have the default browser changed. Not a bad thing, but it's a shame Hildon Desktop doesn't think along the same lines.

I've only tested this under PR 1.1.1 but I see no reason why it'd be different under other versions of Fremantle.
Hildon Desktop will only pick up up changes to the icon of one of its menu entries if you either (perhaps there is more ways but these are the two that I know of): killall hildon-desktop or place a new desktop file in /usr/share/applications/hildon. And I'm not sure that the latter works 100% of the time.

killall hildon-desktop is certain to raise users' eyebrows - the desktop disappearing unexpectedly isn't a nice sight and it's not even certain that it will be respawned. Indeed, it didn't when I killed it to check out the icon change.

Placing a new desktop file will cause some slowdown as the entire folder is scanned and the menu repopulated. And how do you tell that hildon-desktop has finished scanning the folder and has repopulated the menu so that you can delete the desktop file that was placed (I guess that the timestamps of applications.menu may tell you, but I don't know if that's a reliable method.)?

Since PR 1.1, the icon cache has been disabled. Since Browser Switchboard is available for Diablo (its main platform, I'd assume), what about considerations needed there? I haven't touched my N800 or N810 in a long time, but I do remember that updating the icon cache took an age on these devices. And of course, the updating of the icon cache has to be done before Hildon Desktop can know of the new icon to be displayed in the menu.

:)

Want to know an even funnier thing? http://browser.garage.maemo.org/news/9/ (search for 64x54)

Re: Browser Switchboard - use any browser as the default
 

Okay, now you guys are challenging me. Isn't everything we're talking about in open code from these two directories?

http://repository.maemo.org/pool/fremantle/free/h/
http://repository.maemo.org/pool/diablo/free/h/

If so, that could be a fun project: Change the application manager's displayed icons via a dbus call. No restarting of anything. Or like the hilarity below, can you already do that? And aren't these icons redrawn from file when the theme is changed? Those artsy types in the "Mods show us your mods" thread seem to be doing some pretty cool stuff.

Sorry, I'm too dense. Are you saying that the solution wasn't in front of my nose, but on my nose? If so, that's not funny, that's the story of my life. Well, maybe it's kinda funny.