Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: curaga on June 09, 2014, 02:33:55 AM
-
Lately I've been looking into what it would take to have a FLTK port of Webkit.
One thing's become quite clear, a light browser it wouldn't be :p
Webkit parts:
WTF adds ~1mb.
JavascriptCore adds ~11mb. This is with LLVM/FTL disabled.
WebCore adds ~40mb. WebGL, audio, video disabled.
Webkit2 is estimated at ~7mb.
Actual app code estimated at pithy few hundred kb.
Static deps:
libgcc + libstdc++ add ~7mb. These are static because webkit requires rather recent gcc.
ICU adds ~25mb. Static for two reasons: one, it's a few mb smaller than
dynamically; secondly, it's a C++ lib. Having it dynamic would cause galaxies to explode the
first time it threw an exception, as it would bring in the system libstdc++.
Harfbuzz adds ~1mb. Same reasons as ICU.
All stripped binary numbers.
So the binary is already closing in on 100mb! That's some amazing bloat. LTO and other
tricks may get 10% off that, but still quite impressive numbers for a "light" build. LLVM
for example would easily add 50mb.
What would it save, then? Compared to the Qt port, Qt of course, a 140mb+ monster. But to
the other ports of efl and gtk? Perhaps a couple mb and some annoying deps, nothing more.
It may still get done because I'm pissed with the current state of browsers, but it's
heavily looking like "light" is not on the list of features...
-
It may still get done because I'm pissed with the current state of browsers...
I'm curious as to what facet of the current state of browsers you find worst and what might be done about it. The reason I ask is that I'm looking at installing the latest and greatest Firefox to help the company web developer test an application. This is on Windows, but eventually somebody will have to test it on a linux platform.
Right now, I much prefer to stay -way- behind the bleeding edge of browser technology because of what I perceive as "the current state of browsers".
-
Whilst webkit is no doubt huge, some of the deps are shared with other gtk stuff, so perhaps the delta bloat is not as bad as you might think (as long as you use other gtk stuff) - I've been using epiphany and webkit for a while for this reason.
-
@Juanito
Yes, cairo and glib are shared in all cases, as well as some other dynamic deps. I only listed static ones. Of course if you have multiple webkitgtk browsers, then webkit is shared between them.
@Lee
In general, I find the movement to "apps on the web" completely wrong. Javascript is being used for things it has no place in, to the detriment of both developers and users. It is terrible to code in due to many reasons, speaking from experience; badly coded JS hogs cpu like no other, also from experience. Compatibility across browsers is fairly bad, and if one of the big frameworks drops support for the one you use, half the internet breaks.
I also think GL, CL, audio and video do not belong in the browser. Surely integration and games-at-work are nice, but I find that an abuse of the original purpose, sharing information. Games and calculations need native performance, having them shoehorned to the browser just opens up a huge attack surface. The moment WebCL becomes widespread you will see ads that mine bitcoin, throwing users' electricity use up, and that's one of the least malicious uses.
More to the current state, I'm sad of the direction Opera went. Chrome has multiple design choices and default options set such that it collects a lot of data off you, essentially spies on you. It's commonly countered with "you can disable each in the options", but I find it obvious that their being enabled by default conveys quite enough of Google's intent. Further, using Chrome would be like using Facebook: each new update may bring new options, of course set by default to share your information. Whack-a-mole.
Firefox has a bad UI in my opinion, and worse, they keep changing it every few versions. Mozilla has also made a few questionable decisions, such as removing options from the users, and the recent acceptance of DRM.
As the big three are close to unusable, the smaller competitors lack much compatibility (dillo, etc) or features (smaller webkit browsers), what's one to do? Can't exactly keep on using the last workable Opera to eternity.
-
I'm also mad as hell.
But in a twisted way I got to be quite happy about the state of the web lately, it's getting more and more common to get a separation of content and bullshit.
I used to disable javascript selectively on the sites that were using it too much and most of all in the most wrong ways that let my fan go crazy. The term "shit hit the fan" had never felt so justified before.
Nowadays disabling javascript often just gives you a white page, but if you also disable CSS, you still get all the content, haha. I was amazed when I first realised.
The worst is if you have both javascript and CSS enabled. Modern computer "artists" want you to scroll horizontally and click around through mazes like in a first-person shooter. The javascript in no case gets used to do something useful, like to cache the next image in full resolution. No, in most cases it will be used to *hide* all, but one image - actually a scaled-down version, and then I can click it and wait for the frame to load and for the lightbox and the shading effect and.... at least that long fade-in effect gave me enough time to realize I must have js enabled once again. Voila, the images are displayed in full width of my monitor, I can scroll down to see every single one of them, and I can even right-click and download one of them, because there's no javascript trying to tell me: "no, that's illegal, you can't steal this image".
What's the last workable opera for you, 12.14?
Did you look at surf? The people around that project also had a small discussion lately about what to do once webkit-1 is not enough any more.
Did you decide against using gecko as a backend for a fltk thingy?
-
9.64 actually (!!). The great Qt purge in 10.5 to 11.something broke a lot of things, 12 is visibly slower in common things like opening and closing tabs.
Surf: I think I read that ML discussion. The one that ended up "requires a rewrite, not going to happen unless someone does the work"?
Gecko: I didn't look deeper than the official warnings that you shouldn't embed Gecko anymore, it's not really supported that way.
-
I found NetSurf a usable browser for ordinary tasks, reading WEB pages and not playing games, watching video, etc. Rendering is good and it is not based on 3rd-party web engines. It is what I'm using on piCore.
http://www.netsurf-browser.org/
-
9.64 actually (!!). The great Qt purge in 10.5 to 11.something broke a lot of things, 12 is visibly slower in common things like opening and closing tabs.
Setting "Dialog Toolkit" to 4 , disabling special effects and UI animations in opera:config fixes all issues for me. I think it disables some aspects of QT.
Surf: I think I read that ML discussion. The one that ended up "requires a rewrite, not going to happen unless someone does the work"?
Yes, apparently Webkit-1 is good enough for them. And yes, the mailinglist has gotten into a really strange tone lately. You need a good anti-virus for your brain there.
-
4 is the X11 mode which I was using in my tests, unfortunately - the qt and gtk modes were even slower.
-
This leaves me wondering whether this is still about configuration. Or is my core 2 duo just too fast?
-
Probably not, given I have a Phenom X6. It was just worse software.
-
It took me ten days to get a dancing Google logo, over a SSL connection. Not sure if that's good or bad. (nothing else works yet)
(http://i60.tinypic.com/eb33ig.png)
-
Whoa. That is some seriously poor bandwidth. :D
-
73mb binary, widget passthrough in progress. It'll be ready sometime in 2018 at this rate.
(http://i62.tinypic.com/kcih5c.png)
-
3 weeks of webkit porting + 2.5 weeks of browser-side things, and it looks like this:
(http://i58.tinypic.com/14ak9ac.png)
One compiler bug, few hundred features, and two weeks of testing on top before a public alpha.
-
Awesome
-
I didn't expect to ever use webkit again though! *angry* :D
-
The compiler bug was blocking other things, but today it turned out to be a bug in webkit, not in gcc; worked around.
A couple features, then the two-week test remaining before an alpha. The underlying webkit port is already public, so if you want to get a head start to the day-long building: https://github.com/clbr/webkitfltk
-
Thanks, day-long building?? I wonder how long is expected compile time in corepure64 ?
-
Webkit takes ages to build. On my 6-core it's over two hours. Dual core with equivalent speed -> 6h, rpi -> a week ;)
-
Been waiting for a new Cairo release for three weeks now, looks like it will be weeks more. Such is life when the current version is buggy, and one can't test properly without the exact version for fear of breakage.
-
The Cairo release finally happened yesterday. I'll give it a week of testing before release.
edit: In release mode, the final browser binary is 46mb. Much less than the 100mb with asserts (but stripped), but still quite high.
-
It's out: http://fifth-browser.sf.net
It's not TC software per se, so please report bugs and issues to github.
Given the GCC requirement it won't be built for 5.x, 6.x is possible but depends on energy, given the long build times. The portable x64 binary can be run on 5.x though.
-
good news :)
however... make -C Source/WebKit/fltk
...
../../WebCore/dom/EventTarget.h:37:35: fatal error: EventTargetInterfaces.h: No such file or directory
#include "EventTargetInterfaces.h"
I'm guessing this header should be built at some point earlier, but no idea why it isn't :(
-
Will try a build on 6.x maybe tomorrow, maybe later.
-
Given the GCC requirement it won't be built for 5.x, 6.x is possible but depends on energy, given the long build times. The portable x64 binary can be run on 5.x though.
Nice work. Can't get it to run on latest corepure64 though, it complains cairo is too old.
edit: compiling new cairo right now cause I'm so curious.
NICE. Bug report: pressing . finds stuff, but pressing enter doesn't go to where the link of the found text points to :)
opera should have hired you for their webkit shit, haha.
Apart from avoiding compiling webkit I never had a use for corepure64, but today I tried it for the first time. Problem: there is no mplayer extension, so I wonder if anyone is actually using this for his day to day web browsing and slacking off :)
-
Corepure64 is my most frequently used OS on all pc's. I made a small extension which connects to a media server to stream HD video and music, use it for work and browsing the web currently using latest Firefox, Flash and Alsa+PulseAudio and VLC player
Am anxious to to try the Webkit
I built a one click extension which updates all extensions in tce directory
Is great for compiling and for any memory intensive operations
:)
Sent from my iPhone using Tapatalk
-
...I never had a use for corepure64, but today I tried it for the first time. Problem: there is no mplayer extension, so I wonder if anyone is actually using this for his day to day web browsing and slacking off :)
opera-12 and rhythmbox/xmms :)
-
Will try a build on 6.x maybe tomorrow, maybe later.
OK, that was x86_64 and the prior "make" commands all worked without error - cmake wouldn't even configure...
-
BTW, which package links against liburlmatch.a - fifth itself?
-
NICE. Bug report: pressing . finds stuff, but pressing enter doesn't go to where the link of the found text points to :)
Added to the todo list.
opera should have hired you for their webkit shit, haha.
Apart from avoiding compiling webkit I never had a use for corepure64, but today I tried it for the first time. Problem: there is no mplayer extension, so I wonder if anyone is actually using this for his day to day web browsing and slacking off :)
Thanks. I rarely use corepure64 though.
BTW, which package links against liburlmatch.a - fifth itself?
Fifth, yeah. Not used in webkitfltk.
-
physfs uploaded to tc-6.x x86_64 repo
-
..looks like I found the problem - compilation in progress...
-
..but still no luck:
CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" make -C Source/WebKit/fltk
...
g++ -mtune=generic -Os -pipe -c -o dirlisting.o -I .. -I ../.. -I . -I ../../WTF -I webkit -I WebCoreSupport -std=gnu++11 -g -Wall -DBUILDING_FLTK__ -D_GLIBCXX_USE_SCHED_YIELD -D_GLIBCXX_USE_NANOSLEEP -I/usr/local/include -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include/libdrm -I/usr/local/include -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include/harfbuzz -I
../../JavaScriptCore/ForwardingHeaders -I ../../WebCore -I ../../WebCore/ForwardingHeaders -I ../../WebCore/Modules/geolocation -I ../../WebCore/Modules/filesystem -I ../../WebCore/Modules/mediastream -I ../../WebCore/Modules/navigatorcontentutils -I ../../WebCore/Modules/networkinfo -I ../../WebCore/Modules/webdatabase -I ../../WebCore/Modules/websockets -I ../../WebCore/accessibility -I ../../WebCore/bindings/generic -I ../../WebCore/bindings/js -I ../../WebCore/bindings -I ../../WebCore/bridge -I ../../WebCore/bridge/c -I ../../WebCore/bridge/jsc -I ../../WebCore/css -I ../../WebCore/dom -I ../../WebCore/dom/default -I ../../WebCore/editing -I ../../WebCore/fileapi -I ../../WebCore/history -I ../../WebCore/html -I ../../WebCore/html/forms -I ../../WebCore/html/shadow -I ../../WebCore/inspector -I ../../WebCore/loader -I ../../WebCore/loader/archive -I ../../WebCore/loader/appcache -I ../../WebCore/loader/icon -I ../../WebCore/loader/cache -I ../../WebCore/page -I ../../WebCore/page/animation -I
../../WebCore/page/scrolling -I ../../WebCore/platform -I ../../WebCore/platform/animation -I ../../WebCore/platform/audio -I ../../WebCore/platform/fltk -I ../../WebCore/platform/cairo -I ../../WebCore/platform/graphics -I ../../WebCore/platform/graphics/filters -I ../../WebCore/platform/graphics/harfbuzz -I ../../WebCore/platform/graphics/harfbuzz/ng -I ../../WebCore/platform/graphics/cairo -I ../../WebCore/platform/graphics/texmap -I ../../WebCore/platform/graphics/opentype -I ../../WebCore/platform/graphics/transforms -I ../../WebCore/platform/mediastream -I ../../WebCore/platform/mock -I ../../WebCore/platform/network -I ../../WebCore/platform/network/curl -I ../../WebCore/platform/sql -I ../../WebCore/platform/text -I ../../WebCore/plugins -I ../../WebCore/rendering -I ../../WebCore/rendering/line -I ../../WebCore/rendering/shapes -I ../../WebCore/rendering/style -I ../../WebCore/storage -I ../../WebCore/style -I ../../WebCore/svg -I ../../WebCore/svg/animation -I ../../WebCore/svg/graphics -I
../../WebCore/svg/properties -I ../../WebCore/workers -I ../../JavaScriptCore -I ../../JavaScriptCore/API -I ../../JavaScriptCore/assembler -I ../../JavaScriptCore/bytecode -I ../../JavaScriptCore/bytecompiler -I ../../JavaScriptCore/disassembler -I ../../JavaScriptCore/dfg -I ../../JavaScriptCore/heap -I ../../JavaScriptCore/debugger -I ../../JavaScriptCore/interpreter -I ../../JavaScriptCore/jit -I ../../JavaScriptCore/llint -I ../../JavaScriptCore/parser -I ../../JavaScriptCore/profiler -I ../../JavaScriptCore/runtime
-DENABLE_CANVAS_PATH -DENABLE_CHANNEL_MESSAGING -DENABLE_CONTEXT_MENUS -DENABLE_CSS_BOX_DECORATION_BREAK -DENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED -DENABLE_DETAILS_ELEMENT -DENABLE_FTPDIR -DENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING -DENABLE_ICONDATABASE -DENABLE_IMAGE_DECODER_DOWN_SAMPLING -DENABLE_INSPECTOR -DENABLE_JIT -DENABLE_LEGACY_VENDOR_PREFIXES -DENABLE_LINK_PREFETCH -DENABLE_LLINT -DENABLE_METER_ELEMENT -DENABLE_NAVIGATOR_HWCONCURRENCY -DENABLE_PROMISES -DENABLE_PROGRESS_ELEMENT -DENABLE_SVG_FONTS -DENABLE_TEMPLATE_ELEMENT -DENABLE_WEB_SOCKETS -DENABLE_XSLT -DENABLE_SUBPIXEL_LAYOUT -DENABLE_VIEW_MODE_CSS_MEDIA -DENABLE_CURSOR_SUPPORT -DENABLE_DRAG_SUPPORT -DENABLE_FIFTH_VIDEO -DENABLE_VIDEO -DENABLE_VIDEO_TRACK -DENABLE_MATHML -DENABLE_TEXT_CARET -DENABLE_TEXT_SELECTION -DENABLE_WILL_REVEAL_EDGE_EVENTS -DWTF_USE_TEXTURE_MAPPER -DWTF_USE_CROSS_PLATFORM_CONTEXT_MENUS -DENABLE_NETSCAPE_PLUGIN_API=0 -DENABLE_SQL_DATABASE=0 -DENABLE_DATE_AND_TIME_INPUT_TYPES=0 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -Wall -I/usr/local/include -mtune=generic -Os -pipe -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT dirlisting.cpp
dirlisting.cpp: In function 'const char* gendirlisting(const char*)':
dirlisting.cpp:85:51: error: invalid conversion from 'int (*)(const void*, const void*)' to 'int (*)(const dirent**, const dirent**)' [-fpermissive]
const int num = scandir(dir, &names, filter, comp);
^
In file included from dirlisting.cpp:22:0:
/usr/include/dirent.h:254:12: note: initializing argument 4 of 'int scandir(const char*, dirent***, int (*)(const dirent*), int (*)(const dirent**, const dirent**))'
extern int scandir (const char *__restrict __dir,
^
Makefile:139: recipe for target 'dirlisting.o' failed
make: *** [dirlisting.o] Error 1
make: Leaving directory '/usr/src/webkitfltk-0.1/Source/WebKit/fltk'
-
What was the problem? dirlisting thing is a bug, will be fixed soon.
-
edited previous post with more detailed error listing (I had to split the line as it was too long to cut and paste...)
Edit: - looks similar to fltk str#3023 and http://permalink.gmane.org/gmane.comp.lib.fltk.bugs/6551?
Edit2; This seems to fix it, but is it kosher?
static int comp(const void *ap, const void *bp) { -> static int comp(const dirent **ap, const dirent **bp) {
-
The dirlisting thing was fixed in git. What was the issue with the missing header?
-
Really? It must have been pretty recent as I tried git last night...
The missing header was operator error - without my reading glasses, I missed the "make WebCore" step :-[
Now it's baulking at webkit/fltk when it gets to a static link to harfbuzz-icu
-
got there - see screenshot 8)
..trouble is that webkitfltk.a is 340mb and fifth is 41mb (unpacked), but a more manageable 13.7mb as an extension...
-
Yay :) Just curious, how long did it take you to build webkitfltk? What kind of cpu?
You can make it smaller by disabling asserts in webkitfltk, then the webkit lib is only ~130mb. See the latest webkitfltk README.
-
Also, if your bravery is unmatched you could see what *glances around* LTO could do. I haven't had the guts, with rumors being an hour more and 8GB ram minimum.
-
make -j5 -C Source/JavaScriptCore [real 8m 45.67s]
make -j5 -C Source/WebCore [real 39m 56.38s]JavaScriptCore fails to compile with -flto (of course it fails at the final link stage right at the end). Anyway, it still makes static libs larger than without using it most of the time.
Since various Makefiles invoke icu-config, fltk-config, etc, -flto is used in places
cpu is an intel i7-4600 @ 2.10ghz, but I believe it's the 16gb ram that makes the difference.
Not sure if it's useful, but a couple of notes:
* webkit puts headers in include/webkitfltk, but fifth looks for them in include only
* the fifth tarball will not compile due to missing src/genver.sh (and possibly others)
* liburlmatch Makefile is missing "install"
fifth posted to tc-6.x x86_64 repo - I like it :)
-
- header thing has been changed in today's git, pkg-config is now used
- urlmatch install target was added yesterday
The tarball needs some tuning yeah.
-
0.1.1 released with build fixes mainly.
-
One thing I forgot to mention is that I couldn't resize the fifth window from the corner, only from the bottom or side.
-
recompiled webkitfltk with -DNDEBUG and the fifth extension size dropped from 13.7mb to 8.5mb :)
..could be dropped a little more by symlinking the icons?
-
I have to try this :)
-
One thing I forgot to mention is that I couldn't resize the fifth window from the corner, only from the bottom or side.
Probably not something in the app, as in JWM I can resize from corners too.
..could be dropped a little more by symlinking the icons?
Squashfs detects identical files, so a symlink wouldn't save anything.
-
fifth posted in tc-6.x x86 repo
-
Used only for a short time, but looks ok. Just one question. What is about flash support?
-
Explicitly not supported.
-
Explicitly not supported.
^^
Yes, the way forward is open standards!
However, are there some serious efforts in the direction of an IDE like Adobe has for flash, to create HTML5 animations, and working with js?
That you have successfully ported Webkit to FLTK is just amazing!
It's the obvious way forward for FLTK browsing. And I've wanted Dillo improved to at least get the site formatting better implemented.
But to have Webkit, we have a standard, complete implementation of HTML5 and js. Which is just magnificent!
To use FLTK Webkit for a full-time browser is something I want to do. But the only browser I've considered replacing with Firefox is Midori. But it constantly crashes.
Midori has a sidebar for plugins, like script-addons plugin (js addons), and style-addons plugin (css addons).
And then has a C API for writing plugins.
Just with these plugins, and the plugins for ad-blocking and script-blocking, I could start using Midori -- if it didn't always crash, that is.
It comes by default with these excellent plugins, so it's easy to get set up.
From the DESIGN file of Fifth:
No native video support. Every embedded player generally sucks. Instead,
we will offer two buttons in place of HTML5 video elements: download
(as $GOD intended) and stream (ie, launch in your favorite player such
as mplayer).
I really like that, but can't we have mplayer in slave mode for an "embedded" player?
And if there are plugins, we could have a simple plugin for extracting the video from a flash file for streaming/downloading.
Then we could have it act just like any browser, by embedding mplayer (of course just by executing the binary).
I like all of the http://fifth-browser.sourceforge.net/features.html
I will download the latest TC to get Fifth and test it soon (as compiling it would take too long).
But from the screenshots, I have one thing I would like added: to have downloads in a drop-down window, instead of a whole tab. But perhaps there already is such a thing..?
And of course for speeding up community contributions, and involvement, plugins would be great.
No need for an extensive API, just having an icon added for a plugin, and a drop-down window.
Wait... if you want to access FLTK Webkit from a plugin, you'd need to have it dynamically linked...
Well, FLTK Webkit is great, and I will be able to implement it in my GUI integration tool (written in FLTK), so plugins for the web can be written in my own plugin API.
So you would have a complete GUI environment, with web browsing integrated.
But I'm not sure about it, as I've always planned to have just an "information browser", with link containers/menus presented as drop-down windows.
To have text presented in 60-80 characters wide, for easy reading by pretty much just placing your eyes in the middle of the text, and scrolling.
Anyways, great work!
-
Fifth has native content blocking (which works for any URL, so CSS, ads, images, JS, whatever). Compiled plugins would be a lot of work for little gain (yes, it would need extensive API), any such functionality can be built in for the same amount of work from the plugin author.
Download feature request noted.
-
Fifth has native content blocking (which works for any URL, so CSS, ads, images, JS, whatever). Compiled plugins would be a lot of work for little gain (yes, it would need extensive API), any such functionality can be built in for the same amount of work from the plugin author.
Download feature request noted.
Excellent!
I already understood that there must be some blocking and overriding of scripts and CSS, but I didn't see any screenshots of the feature (so that would be nice).
The downloads drop-down, is from the design principle of New Room... something... where you walk into a room and forget why you were there (context-dependent memories is something we all have to deal with).
You can still have the drop-down window as big as you want.
But plugins is one of the reasons I kind of love Midori, even when it's unusable (yes, I have the latest version, through Arch Linux).
Plugins brings the ultimate configurability to technical users. Even if you aren't a very good programmer, you can still easily mod existing plugins (a good way to learn programming, as well).
But of course, you have clearly stated that it's your browser, first of all ^^
I'm happy enough to have Webkit for FLTK.
-
..not sure whether it's webkit, fifth or fltk, but when using fifth to download a file to the default location - /tmp/filename - the file name is kept.
When navigating to a location other than /tmp, the filename is lost and the user is obliged to enter it again.
-
That's FLTK's file chooser, same thing in all FLTK apps. If you use some other location more often than /tmp, the default can be changed in the advanced settings.
-
Hi everyone,
I've been trying to set up midori in TC v5.4, but on Juanito's suggestion I've been looking at fifth on TC v6.0 RC1 too. (It seems that people at my office are interested too) It is pretty lightweight, but I haven't figured out how to make fifth fullscreen, which we really need. And also when we entered into the advance configuration, we can't save the changes we've made. After restarting fifth, we don't see any changes and everything in the advance configuration goes back to default settings.
But still our main question is: is fullscreen (like F11 on other firefox) possible?
-
Fullscreen is not implemented yet. As mentioned in the other thread, it would be faster to build a new app using webkitfltk than to adapt a browser, as for kiosk usage you don't need tabs/history/etc etc. You would create a fullscreen window, add a web widget, point it to your URL.
edit: Thanks for the bug report, it was one that didn't show in debug builds, only in release, which explains why it wasn't seen before. Fixed in git.
-
As mentioned in the other thread, it would be faster to build a new app using webkitfltk than to adapt a browser, as for kiosk usage you don't need tabs/history/etc etc.
You're right Curaga. Thanks for the tip! I'll try to look into that....
-
It would be helpful if the fifth search box were not cleared each time the web page is changed as a user is likely to be searching for the same thing on multiple web pages.
-
The inner state is not cleared, if you search (ctrl-f or period), switch tabs, pressing F3 searches for the same string. It's just the textbox, same as in Opera.
-
I finally had the courage to try LTO, with GCC 5.2. -flto=6 caused a swapstorm, -flto=3 allowed things to build. After waiting a while and having spent gigs of RAM, the fifth binary is 14.5% smaller, and seems a bit faster too.
No crashes or anything surprising yet. If it survives a week, time for a new release.