Active Topics

 



Notices


Reply
Thread Tools
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#81
Originally Posted by steven676 View Post
With Browser Switchboard installed, we have to separate the two, so the question is whether users expect the item named "Web" to bring up the browser shipped with the device, or whether they expect it to bring up the default browser they've chosen using Browser Switchboard.
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.

Last edited by qwerty12; 2010-02-17 at 11:42.
 

The Following 2 Users Say Thank You to qwerty12 For This Useful Post:
daperl's Avatar
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#82
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
...
__________________
N9: Go white or go home
 

The Following 2 Users Say Thank You to daperl For This Useful Post:
jukey's Avatar
Posts: 246 | Thanked: 204 times | Joined on Jun 2007 @ Potsdam (Germany)
#83
Originally Posted by qwerty12 View Post
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.
I agree with this point of view.
__________________
-> Join the SailfishOS Meetup Berlin - every first Monday a month <-

Me on twitter
 

The Following User Says Thank You to jukey For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#84
Originally Posted by daperl View Post
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.
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.

Originally Posted by daperl View Post
And instead of renaming Icon: entries in .desktop files, for instance, just actually overwrite the actual .png files.
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.

Originally Posted by daperl View Post
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
...
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.
 

The Following 3 Users Say Thank You to steven676 For This Useful Post:
daperl's Avatar
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#85
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.
__________________
N9: Go white or go home
 

The Following 2 Users Say Thank You to daperl For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#86
Originally Posted by daperl View Post
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.
Was that the discussion on how to duplicate Diablo MicroB's favicons in the task list?

Originally Posted by daperl View Post
What you guys are doing interests me because I've been hacking on some mediaplayer stuff, and I might want to do something similar.
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!
 

The Following User Says Thank You to steven676 For This Useful Post:
daperl's Avatar
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#87
Originally Posted by steven676 View Post
Was that the discussion on how to duplicate Diablo MicroB's favicons in the task list?
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.

but from a backend perspective (at least in my opinion) it doesn't work that well.
If you feel like it, I wouldn't mind a short synopsis why you think so.

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!
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.
__________________
N9: Go white or go home
 

The Following 2 Users Say Thank You to daperl For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#88
Originally Posted by daperl View Post
If you feel like it, I wouldn't mind a short synopsis why you think so.
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
 

The Following 2 Users Say Thank You to steven676 For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#89
Originally Posted by daperl View Post
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.
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.

Originally Posted by daperl View Post
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.


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

Last edited by qwerty12; 2010-02-18 at 13:00.
 

The Following 2 Users Say Thank You to qwerty12 For This Useful Post:
daperl's Avatar
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#90
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.

Originally Posted by qwerty12 View Post
Want to know an even funnier thing? http://browser.garage.maemo.org/news/9/ (search for 64x54)
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.
__________________
N9: Go white or go home
 

The Following 2 Users Say Thank You to daperl For This Useful Post:
Reply

Tags
browser, default, microb, opera


 
Forum Jump


All times are GMT. The time now is 18:41.