(old)Puppy Linux Discussion Forum

https://github.com/vurtun/nuklear

Features:

* Immediate mode graphical user interface toolkit
* Single header library
* Written in C89 (ANSI C)
* Small codebase (~15kLOC)
* Focus on portability, efficiency and simplicity
* No dependencies (not even the standard library if not wanted)
* Fully skinnable and customizable
* Low memory footprint with total memory control if needed or wanted
* UTF-8 support
* No global or hidden state
* Customizable library modules (you can compile and use only what you need)
* Optional font baker and vertex buffer output

I'd like to do a smallish project with this.
... maybe a permissively licensed gtkdialog clone or something similar?
... maybe a gtk compatibility wrapper?
Any thoughts?

What about a menu application free of the window manager.

technosaurus wrote:I'd like to do a smallish project with this.
... maybe a permissively licensed gtkdialog clone or something similar?
...

I'd like the idea of a gtkdialog clone - easy showcasing of the toolkit.

How small in size is it compared to gtk?

In the pictures I can see widgets, but is there a canvas?

Looking at the system size projections of the future, size is not important. Only code path & machine-level instructions used in code-path.

Question

• Assuming the toolkit will be supported by its author-team into the future, will the GTK+ Replacement have a similar ongoing support?

Looks interesting.

technosaurus wrote:I'd like to do a smallish project with this.
... maybe a permissively licensed gtkdialog clone or something similar?
... maybe a gtk compatibility wrapper?
Any thoughts?

With QT-5.6 upon us Qupzilla is using qt-webengine (very capable). There are plenty of file managers, text editors and other stuff that can run without gtk. The dialog clone will be very useful. We could shrink this thing again! Even with other display managers (other than X11 - thinking forward).

BarryK wrote:In the pictures I can see widgets, but is there a canvas?

The "canvas" is used in a custom widget for that weird round selector dealy: https://github.com/vurtun/nuklear/blob/ ... nded.c#L67

gcmartin wrote:Looking at the system size projections of the future, size is not important.

Contrary to popular belief, size does matter. Future CPU architectures aren't adding much if any L1 or l2 cache, so really it does... any binary that excedes ~64KB (32KB Data+32KB Instruction) takes a performance hit by not fitting in L1. It takes another hit if it grows beyond L2 capacity (~256KB - typical). Newer CPU/GPU combos can have several MB of on-die L3 cache (Intel's Haswell has 128MB shared between CPU and GPU), but keep in mind that current desktop environments already exceed 128MB or even 256MB with no "applications" running.

Scooby wrote: I'd like the idea of a gtkdialog clone - easy showcasing of the toolkit.

How small in size is it compared to gtk?

It's a couple of orders of magnitude smaller than gtk.
Perhaps the best path forward would be to write just enough wrappers for gtk functions so that gtkdialog can build. Afterwards additional wrappers could be added for additional Puppy apps (ROX, Seamonkey, etc...).

I have gotten it to compile in slacko, but the standard version needs an Xserver with GL support. I ported some stuff to use its X11 backend and even had the file browser ported to linux except for images before I bumped the battery loose in my laptop - it shouldn't be hard to get it going again since I've already done it once and the image parts use stb-image (which I have used before along with nanosvg for svg support)

technosaurus wrote:I have gotten it to compile in slacko, but the standard version needs an Xserver with GL support. I ported some stuff to use its X11 backend and even had the file browser ported to linux except for images before I bumped the battery loose in my laptop - it shouldn't be hard to get it going again since I've already done it once and the image parts use stb-image (which I have used before along with nanosvg for svg support)

Hey man, sorry about the battery incident.

That is so annoying when you loose work and have to redo it.

Happens to me sometime when I was not careful with RAM and maxed
it out since I am running without savefile work is sometimes lost.

But as you say if you done it once you sure can do it a second time.

Awaiting your findings...

I was looking for some alternative to GTK+ , I have resorted to using Qt in C++ ( saves a lot of time ). Thank You.

abhishek-kumar wrote:I was looking for some alternative to GTK+ , I have resorted to using Qt in C++ ( saves a lot of time ). Thank You.

I looked into that a while ago, but, as far as I remember, using Qt in programming required a very large development environment or have you found otherwise? What are you using and from where?

William

@mcewanw I am using sfs provided by tahrpup (from sfsget ) they work fine they are pretty lite. Atleast lighter than eclipse and android SDK . Java hogs the system resources so much, I avoid Java for personal development. Few of my prototypes were in Qt 4.8 , since at that time new versions of Qt were not available at that time. I still use Qt 4.8 for some minor game developments. They are pretty lite.

SFS of newer versions could get heavy for very old systems, if that is the case use this sfs Qt 4.8 toolkit they are pretty light.

http://puppylinux.org/wikka/qt

(however this one is not of tahrpup but works on any debian/ubuntu derivatives of puppy linux {upup} )

Any news ... ?
Only interested in visual appearance features.
Aside from scrollbar and merge there's nothing wrong with gtk2, however
some alternative would be nice...

technosaurus wrote:I have gotten it to compile in slacko, but the standard version needs an Xserver with GL support. I ported some stuff to use its X11 backend and even had the file browser ported to linux except for images before I bumped the battery loose in my laptop - it shouldn't be hard to get it going again since I've already done it once and the image parts use stb-image (which I have used before along with nanosvg for svg support)

Technosaurus,
Any progress with the X11 backend?

A nice little project would be a Linux equivalent to the Windows Usb Image Tool -- see my blog announcement for SlaQ, with link to install instructions and info on USB Image Tool.

If it could be compiled statically, it would run on any Linux. Compile it as i686 and it will also run in x86_64 Linuxes.

...just responding to your question about what would be a good little project!