Active Topics

 


Reply
Thread Tools
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#61
Originally Posted by Android_808 View Post
did manage to get a vm set up and working yesterday. i like the ui that was in the original maemo preview as it was similar to microb. i think it would be better sticking with something like that but in qt not qml.

i can't remember the exact reason for not using gtk (issue gl canvas is floating around in my head), but we have some underlying components of microb reverse engineered, jonwill iirc did some. would it not be better to aim at making it a drop in replacement for what we already have.
Well, after some research, qml might not be the best option: bugs in qt components. But I'll try out updated qt components and let know

As for me it'd be the best to check if the current harmattan UI, whether it works. Then we can debate what to do next.

Well, using the microb ui would be good too.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#62
I will admit I haven't got round to delving to deep into it as of yet. If API is still compatible with microb UI I think it would make sense to just rebase microb patchset against latest xulrunner/FF sources or the latest LTS/Enterprise release (or whatever their calling it). The patches aren't that complicated to follow what their aim is. Some (eg. gstreamer) have updated versions kicking about on Mozilla mailing lists. Doing this will clean up where all the functionality needs to be added/edited to replace Hildon/GTK UI embedded in the engine itself if you decide on QT/QML. Mainly dialogue boxes IIRC.

I know there are some internal changes stopping the patches applying cleanly without some minor editing (last checked against FF7/8) but as long as the functions called by the closed source UI packages are unchanged it may be workable. This way at least we would have an up to date, secure(r) base on which to work. If API has changed then the existing UI would have to be RE'd/replaced.
 

The Following 3 Users Say Thank You to Android_808 For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#63
Originally Posted by Android_808 View Post
If API is still compatible with microb UI I think it would make sense to just rebase microb patchset against latest xulrunner/FF sources or the latest LTS/Enterprise release (or whatever their calling it).
No radical changes in API during so many years in something FF-related? I really doubt that, sadly. IIRC freeman&co checked it, once, and it was totally incompatible, but I may be referring to something only vaguely related, so don't quote me on it.

But, having open backend and "only" frontend" closed, can't we compare how "old" open backend communicate with closed UI, as related to "new" backend API? Or am I missing something?

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 2 Users Say Thank You to Estel For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#64
without looking into it further, i wouldn't know what parts of API have changed. maybe it would have been better to say I know there have been some (java), but i don't know how they affect the subset of functions used by the UI.
 

The Following 2 Users Say Thank You to Android_808 For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#65
Originally Posted by Android_808 View Post
without looking into it further, i wouldn't know what parts of API have changed. maybe it would have been better to say I know there have been some (java), but i don't know how they affect the subset of functions used by the UI.
Well, nevertheless we need to find out how to build it! We can discuss infinite-long about "which ui to use", but it'll be nothing if we can't build the app!

When we have everything built, then we can discuss "what to do next". Can you try to do it, as I failed the time I tried?
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#66
Originally Posted by Android_808 View Post
without looking into it further, i wouldn't know what parts of API have changed. maybe it would have been better to say I know there have been some (java), but i don't know how they affect the subset of functions used by the UI.
GtkMozEmbed is not in the tree for long time. And that's what microb uses.

*Maybe* it is possible to tell gecko to render to bc-cat texture which has its memory from a GTK pixmap, and somehow "lie" microb to show that pixmap, but I don't think we can achieve something like that without someone knowing the internals of both microb and gecko.

The other option is to rewrite microbui with Qt, that's what qwazix started to do...
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 3 Users Say Thank You to freemangordon For This Useful Post:
Posts: 466 | Thanked: 335 times | Joined on Jan 2010 @ Vienna, Austria
#67
cool, so this project is not dead after all! Last time I visited here, I only saw months-old posts, and not promising ones.
Kudos to all of you who look into this!
 
Posts: 804 | Thanked: 1,598 times | Joined on Feb 2010 @ Gdynia, Poland
#68
Originally Posted by marmistrz View Post
Well, nevertheless we need to find out how to build it! We can discuss infinite-long about "which ui to use", but it'll be nothing if we can't build the app!

When we have everything built, then we can discuss "what to do next". Can you try to do it, as I failed the time I tried?
+1, I wanted to build the app for non-thumb, but failed due to lack of instructions what to do (code in 4 linked repos differed, and I failed to cleanly build all 4 version in scratchbox - there might be a slight chance that my setup's broken, but I don't remember any other package that failed to build, and I compile a lot of stuff for my own purposes, so I doubt).

Edit: the best option would be to have the source packages (tgz + dsc) uploaded somewhere - then it would be trivial to recompile (or definitely blame building toolchain for failures).

Another edit: oh, I see there are "debian" directories in the repositories (at least the tmeshkova version has one), I'm gonna try again quite soon

Last edited by misiak; 2013-11-17 at 18:45.
 

The Following 2 Users Say Thank You to misiak For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#69
Originally Posted by misiak View Post
+1, I wanted to build the app for non-thumb, but failed due to lack of instructions what to do (code in 4 linked repos differed, and I failed to cleanly build all 4 version in scratchbox - there might be a slight chance that my setup's broken, but I don't remember any other package that failed to build, and I compile a lot of stuff for my own purposes, so I doubt).

Edit: the best option would be to have the source packages (tgz + dsc) uploaded somewhere - then it would be trivial to recompile (or definitely blame building toolchain for failures).

Another edit: oh, I see there are "debian" directories in the repositories (at least the tmeshkova version has one), I'm gonna try again quite soon
you can't build latest gecko with 4.2.1, IIRC the minimum required version is 4.4

you'll need python2.7 and export PYTHON=/usr/bin/python2.7

debian dir on tmeshkova supports maemo5 build under cssu-thumb target, never tried it in stock SB armel target


EDIT:
It was a while I tried to build gecko for maemo5 for the last time, latest code might not compile or run
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 4 Users Say Thank You to freemangordon For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#70
I've tried pulling in https://github.com/tmeshkova/xulrunner-package and running ./build -t fremantle. It looks as though it should be pulling in the other repos from tmeshkova repo as well.

1. can't pull https git clone. even with devkit, and symlink in /usr/share/curl. Worked with git://
2. requires a sb target called FREMANTLE_ARMEL_GCC472. I have this installed as part of FREMANTLE_THUMB target. I cheated by symlinking target directory for now, just to see how far it would go.
3. fremantle build target calls a routine to check for sb2. I don't have this setup.

freemangordon, you posted gcc info whilst i was typing

Last edited by Android_808; 2013-11-17 at 20:08.
 

The Following User Says Thank You to Android_808 For This Useful Post:
Reply

Tags
gecko browser, maemo 5


 
Forum Jump


All times are GMT. The time now is 02:48.