Linux GUI programming

[Sevag.K]

Any way I have tried compiling the hidelib on linux before but it never worked because it kept giving me errors that something was undefined.

i used to have a working makefile, but it got crashed with my old computer.

I hadn't tried with the most recent version, I downloaded another copy a little ago but hadn't tried yet.

mem2.fillMem function is in the library right ? so get hidelib to compile and then we wouldn't have to rewrite that function ?

correct, but mem2.fillMem is a simple function, a few lines,  you don't have to go through the hassle of rebuilding the entire library just for that.

Code Select Expand


procedure mem2.fillMem (var lpSource:dword; MemSize:dword; Value:byte );
@noframe; @nodisplay; @noalignstack;

begin fillMem;

push( ebp );
mov( esp, ebp );
push( eax );
push( edi );
push( ecx );

cld();
mov( lpSource, edi );
mov( MemSize, ecx );
mov( Value, al );
rep.stosb();

pop( ecx );
pop( edi );
pop( eax );
pop( ebp );
ret( _parms_ );

end fillMem;


Hidelib doesn't have anything windows speciifc does it ? I think the problem I always have in trying to compile is that either HLA can't find the necessary headers (maybe cause linux is case sensitive) or that there is a difference between the headers and the source.

no windows specific code.  it just uses hlalib and other hidelib functions.  it needs the macros and headers from the HIDE package, expecting them to be on your %hlainc%/hide and %hlainc%/macros paths.  but the headers are also in the src directory of hidelib project, they just need to be copied to the correct paths above.

HOWL for the other versions of HLA would be nice but I don't expect that anytime soon ( like 64bit support :P ) Randall doesn't release anything till it's how he wants it or it is working correctly and I wish some Linux devs had that attitude.

I was thinking how it would be easier (in the long run) if wForm was wrapped inside an object called uiForm which would be wForm on winodws as it is now; xForm for Linux/BSD and aForm for MacOS (Aqua is default right ? X needs installed on Macs) That way like HLA is now HOWL could be supported on multiple platforms with just a recompile.

i think the idea is to have it cross platform in the future, it's just that linux gui programming is arsed compared to windows, especially when starting from scratch.  that's the main reason i abandoned work on guilib... it took me several days of searching and asking just to figure out how interrupt a close button click on a window.

[latte]

HIDE is released as copyrighted opensource freeware (cannot released under a different license)
HIDELIB is public domain opensource.

Hi Sevag -
Thanks very much for clarifying that - that's great!  
Interesting that you mention that Linux GUI programming is, umm, "arsed"...  :wink   
I'm a bit of a fan of the Plan 9 OS.  Apparently in that, everything is treated as a file (Unix and Linux do that to a certain extent, but Plan 9 goes all the way).  Anyway, if Linux had used that approach to things, I wonder if that would have made things easier as far as GUI coding goes?  It would seem to, but I'm not an expert. 
- latte

[Sevag.K]

i'm not familiar with plan 9 OS.  sounds like a B movie.
the biggest problem with linux gui is that it was added in as an afterthought and everybody added their own bit to it as the years went by.

while i like gui "skins" and customizations, i'm no fan of different implementations.  there should be only one, well documented graphics kernel.  in this one thing probably the opensource bit was not such a good idea for linux.

[latte]

i'm not familiar with plan 9 OS.  sounds like a B movie.

In fact, you're exactly right - that *is* what it is named after.  A move called "Plan 9 from Outer Space", by Ed Wood.  It is widely regarded as the worst movie ever made.   
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

the biggest problem with linux gui is that it was added in as an afterthought and everybody added their own bit to it as the years went by.

Ok.  Yes, that'd mean that the gui would end up as a real mish-mash.  No good long-term planning and design.   

while i like gui "skins" and customizations, i'm no fan of different implementations.  there should be only one, well documented graphics kernel.  in this one thing probably the opensource bit was not such a good idea for linux.

Ok. 
- latte

[DarkWolf]

Yes building the hidelib for one function may be over kill but not if I also make use of other functions as well.

I had to correct for case sensitivity (all lower case filenames work)
But I still end up with some errors in class_list_remove.hla

Code Select Expand


$ hla -c src/*.hla
Error in file "src/class_list_remove.hla" at line 25 [errid:38698/hlaparse.bsn]:
Identifier "node_t" must be identical to  declaration "lNode".
Near: << ) >>

Error in file "src/class_list_remove.hla" at line 25 [errid:24125/hlaparse.bsn]:
This class method has not been overridden.
Near: << ) >>

Error in file "src/class_list_remove.hla" at line 34 [errid:128231/hlaparse.c]:
syntax error, unexpected ',', expecting ':' or '.'.
Near: << , >>

HLAPARSE assembly failed with 3 errors


And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.
The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.

[Sevag.K]

Yes building the hidelib for one function may be over kill but not if I also make use of other functions as well.

I had to correct for case sensitivity (all lower case filenames work)
But I still end up with some errors in class_list_remove.hla

Code Select Expand


$ hla -c src/*.hla
Error in file "src/class_list_remove.hla" at line 25 [errid:38698/hlaparse.bsn]:
Identifier "node_t" must be identical to  declaration "lNode".
Near: << ) >>

Error in file "src/class_list_remove.hla" at line 25 [errid:24125/hlaparse.bsn]:
This class method has not been overridden.
Near: << ) >>

Error in file "src/class_list_remove.hla" at line 34 [errid:128231/hlaparse.c]:
syntax error, unexpected ',', expecting ':' or '.'.
Near: << , >>

HLAPARSE assembly failed with 3 errors


oops, legacy code, just delete that file.  i've just done it on my end.  the remove method for tList moved to the superclass tBaseList several versions ago.

And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.
The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.

yup.  the mac is beginning to look like a good option as this point.  alas, i don't have the hardware cohones to build a mac-box and anything with an apple sticker on it is $500 overpriced.

[TmX]

while i like gui "skins" and customizations, i'm no fan of different implementations.  there should be only one, well documented graphics kernel.  in this one thing probably the opensource bit was not such a good idea for linux.

you mean stuffs like GTK, Qt, etc?
probably the solution is to write ASM wrappers which could cope them all, like LCL (Lazarus Component Library)
it works well with GTK1, GTK2, Qt, Cocoa, etc

[DarkWolf]

while i like gui "skins" and customizations, i'm no fan of different implementations.  there should be only one, well documented graphics kernel.  in this one thing probably the opensource bit was not such a good idea for linux.

you mean stuffs like GTK, Qt, etc?
probably the solution is to write ASM wrappers which could cope them all, like LCL (Lazarus Component Library)
it works well with GTK1, GTK2, Qt, Cocoa, etc

No, I think the move should be to use OpenGL with X.
Use X to handle the window process and Opengl for graphics.
There was somewhere I saw a tutorial for that.
The problem is that OpenGL is still a complicated beast for something simple.
The example I saw turned a twenty line code in to almost 50. A 100% increase for just one intrepeted layer.

Sevag's GUILIB idea was propably spot on.

[DarkWolf]

oops, legacy code, just delete that file.  i've just done it on my end.  the remove method for tList moved to the superclass tBaseList several versions ago.

You mean "src/class_list_remove.hla" right ? My download wasn't that old. The whole file is not used ?

yup.  the mac is beginning to look like a good option as this point.  alas, i don't have the hardware cohones to build a mac-box and anything with an apple sticker on it is $500 overpriced.

Even if you could build a "mac" box. You can't buy the OS it only comes with the hardware (as far as I know). It's a package deal.

[Sevag.K]

oops, legacy code, just delete that file.  i've just done it on my end.  the remove method for tList moved to the superclass tBaseList several versions ago.

You mean "src/class_list_remove.hla" right ? My download wasn't that old. The whole file is not used ?

yes, the entire file is not used.  delete it no problem.

It's probably been there for a while, but since HIDE has a built in make file in the .hpr, i removed it from the .hpr but forgot to delete it from the drive (actually HIDE was supposed to delete it when i removed it from the project, but there must have been a bug that prevented this).

this is the pseudo make list for the project as it stands in the latest version

Code Select Expand


version 1.72.03

hidelib.lib
hidefunc.lib
scan.lib
class.lib
bufferclass.lib
configclass.lib
strbuffer.lib
listclass.lib

hidefunc.lib
src/env2_envunit.hla
src/hide_data.hla
src/hide_info.hla
src/hide_putmem.hla
src/hide_putn.hla
src/hide_putz.hla
src/hide_stricmp.hla
src/mem2_size.hla
src/os2_getmodulepath.hla
src/os2_sysexec.hla

scan.lib
src_scanlib/scan_extract.hla
src_scanlib/scan_find.hla
src_scanlib/scan_findc.hla
src_scanlib/scan_ifind.hla
src_scanlib/scan_imatch.hla
src_scanlib/scan_imatchword.hla
src_scanlib/scan_irfind.hla
src_scanlib/scan_lines.hla
src_scanlib/scan_match.hla
src_scanlib/scan_matchword.hla
src_scanlib/scan_pfind.hla
src_scanlib/scan_rfind.hla
src_scanlib/scan_skipalphanum.hla
src_scanlib/scan_skipws.hla
src_scanlib/scan_tokens.hla

class.lib
src/class_clone.hla
src/class_stack.hla

bufferclass.lib
src_class_buf/class_buf.hla
src_class_buf/class_buf_bof.hla
src_class_buf/class_buf_delete.hla
src_class_buf/class_buf_eof.hla
src_class_buf/class_buf_eq.hla
src_class_buf/class_buf_getindex.hla
src_class_buf/class_buf_ieq.hla
src_class_buf/class_buf_iseof.hla
src_class_buf/class_buf_left.hla
src_class_buf/class_buf_moveto.hla
src_class_buf/class_buf_putb.hla
src_class_buf/class_buf_putbuffer.hla
src_class_buf/class_buf_putd.hla
src_class_buf/class_buf_putfile.hla
src_class_buf/class_buf_putl.hla
src_class_buf/class_buf_putq.hla
src_class_buf/class_buf_puts.hla
src_class_buf/class_buf_putw.hla
src_class_buf/class_buf_right.hla
src_class_buf/class_buf_sub.hla
src_class_buf/class_buf_substring.hla
src_class_buf/class_buf_write.hla
src_class_buf/class_buffer.hla
src_class_buf/class_buffer_block.hla
src_class_buf/class_buffer_cmp.hla
src_class_buf/class_buffer_cursor.hla
src_class_buf/class_buffer_del.hla
src_class_buf/class_buffer_extract.hla
src_class_buf/class_buffer_info.hla
src_class_buf/class_buffer_insert.hla
src_class_buf/class_buffer_line.hla
src_class_buf/class_buffer_lineword.hla
src_class_buf/class_buffer_match.hla
src_class_buf/class_buffer_misc.hla
src_class_buf/class_buffer_out.hla
src_class_buf/class_buffer_read.hla
src_class_buf/class_buffer_replace.hla
src_class_buf/class_buffer_search.hla
src_class_buf/class_buffer_searchr.hla
src_class_buf/class_buffer_token.hla
src_class_buf/class_bufferbase.hla

configclass.lib
src_class_config/class_config.hla
src_class_config/class_config_bool.hla
src_class_config/class_config_cpysec.hla
src_class_config/class_config_del.hla
src_class_config/class_config_hex.hla
src_class_config/class_config_int.hla
src_class_config/class_config_item.hla
src_class_config/class_config_itemtokens.hla
src_class_config/class_config_real.hla
src_class_config/class_config_rename.hla
src_class_config/class_config_sections.hla
src_class_config/class_config_strings.hla
src_class_config/class_config_uns.hla

strbuffer.lib
src/class_strbuffer.hla
src/class_strbuffer_get.hla
src/class_strbuffer_info.hla
src/class_strbuffer_put.hla

listclass.lib
src/class_baselist.hla
src/class_baselist_node.hla
src/class_baselist_utils.hla
src/class_flist.hla
src/class_flist_find.hla
src/class_flist_funcs.hla
src/class_flist_remove.hla
src/class_list.hla
src/class_list_find.hla
src/class_list_set.hla


any file that's not in this list is not a part of the project.

Even if you could build a "mac" box. You can't buy the OS it only comes with the hardware (as far as I know). It's a package deal.

you can buy the os and install it on hardware built up from scratch.  there are some tutorials for doing this online, but my skill with hardware stops at installing memory.

[latte]

(snip)
And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.

Agreed!  Yes, it makes one wonder how on earth it all got so complicated.   

The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.

Yes, also agreed.
How on earth people can say that X is the best thing since sliced bread is beyond me...  :)   
- latte

[DarkWolf]

- sevag -

I had not realized that hidelib was made up of other libs.
The linux iinstructions in the package indicates a "flat" library.
Does archivers (as in library porgrams like ar) merge these or can one make a "tree" of library files in one lib file.

( Or is the make file that way just to maintain the library ? )

- latte -

If I understand how it works coorectly.
The original guilib executable from sevag zip file uses only X api functions.
But if I run it beside a GTK or Qt app, you won't notice a difference because the theming is handled by my Gnome Desktop.
Why anyone would bite my head off in a linux newsgroup when I asked for more tutorials on how to do this is beyond me.

Aside from the lack of resources/icons can anyone spot the difference between an X and GTK app ?

[DarkWolf]

src/class_baselist_node.hla  does not to appear to exist in the hidelib.zip archive and you don't list it in your kmake file.

( Please ignore my logging; it's how I do things :P  )

I tried to emulate your kmake file in a makefile.
Results :

Code Select Expand


$ make hidelib.a
date -u +%F_%T >> log/build.log
hla -c src/env2_envunit.hla >> log/build.log
hla -c src/hide_data.hla >> log/build.log
hla -c src/hide_info.hla >> log/build.log
hla -c src/hide_putmem.hla >> log/build.log
hla -c src/hide_putn.hla >> log/build.log
hla -c src/hide_putz.hla >> log/build.log
hla -c src/hide_stricmp.hla >> log/build.log
hla -c src/mem2_size.hla >> log/build.log
hla -c src/os2_getmodulepath.hla >> log/build.log
Error in file "src/os2_getmodulepath.hla" at line 36 [errid:27596/output.c]:
Parameter type mismatch (zstr).
Near: << , >>


It has a problem with str.cpyz maybe ?

Code Select Expand


HLAPARSE assembly failed with 1 errors
hla -c src/os2_sysexec.hla >> log/build.log
Error in file "src/os2_sysexec.hla" at line 102 [errid:77411/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.tokenize2').
Near: << ( >>


There doesn't appear to be a str.tokenize2 func is this supposed to be tokenize4 or tokenize3 ?

Code Select Expand


HLAPARSE assembly failed with 1 errors
ar -vr hidefunc.a src/env2_envunit.hla >> log/build.log
ar: creating hidefunc.a
ar -vr hidefunc.a src/hide_data.hla >> log/build.log
ar -vr hidefunc.a src/hide_info.hla >> log/build.log
ar -vr hidefunc.a src/hide_putmem.hla >> log/build.log
ar -vr hidefunc.a src/hide_putn.hla >> log/build.log
ar -vr hidefunc.a src/hide_putz.hla >> log/build.log
ar -vr hidefunc.a src/hide_stricmp.hla >> log/build.log
ar -vr hidefunc.a src/mem2_size.hla >> log/build.log
ar -vr hidefunc.a src/os2_getmodulepath.hla >> log/build.log
ar -vr hidefunc.a src/os2_sysexec.hla >> log/build.log
date -u +%F_%T >> log/build.log
hla -c src_scanlib/*.hla >> log/build.log
ar -vr scan.a src_scanlib/*.o >> log/build.log
ar: creating scan.a
date -u +%F_%T >> log/build.log
hla -c src/class_clone.hla >> log/build.log
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 42 [errid:128231/hlaparse.c]:
syntax error, unexpected typeTkn.
Near: << type >>


Ignore I just realized my makefile had me adding hla files to the library file (doh!)

Code Select Expand


Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 47 [errid:128231/hlaparse.c]:
syntax error, unexpected endrecordTkn.
Near: << endrecord >>

HLAPARSE assembly failed with 2 errors
hla -c src/class_stack.hla >> log/build.log
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 42 [errid:128231/hlaparse.c]:
syntax error, unexpected typeTkn.
Near: << type >>

Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 47 [errid:128231/hlaparse.c]:
syntax error, unexpected endrecordTkn.
Near: << endrecord >>


?? I was going to ask about the record but I also noticed that you declare a type section inside a class; I thought that was forbidden ??
But you seem to do that in several places but only this one instance gets flagged.
Now that I fixed the commands to not add the hla files to the library this error disappears ??

Code Select Expand


HLAPARSE assembly failed with 2 errors
ar -vr class.a src/class_clone.o src/class_stack.o >> log/build.log
ar: creating class.a
ar: src/class_clone.o: No such file or directory
make: *** [class.a] Error 1


Ignore this; failed since the object files couldn't be built.

[Sevag.K]

- sevag -

I had not realized that hidelib was made up of other libs.
The linux iinstructions in the package indicates a "flat" library.
Does archivers (as in library porgrams like ar) merge these or can one make a "tree" of library files in one lib file.

( Or is the make file that way just to maintain the library ? )

i set it up into different libraries for maintenance reasons.  lib/link on windows can combine them into one contiguous library.  i don't know how ar works, but you don't have to build separate libraries at all.  one flat library will work just fine.

- latte -

If I understand how it works coorectly.
The original guilib executable from sevag zip file uses only X api functions.
But if I run it beside a GTK or Qt app, you won't notice a difference because the theming is handled by my Gnome Desktop.

that is the way it should function.  in the original when i had "khla" (now discontinued) to build it, only x-lib was linked in.  i believe i was working under a kde environment at that time.  so the only difference you would notice is the way the window borders/title are drawn.

Why anyone would bite my head off in a linux newsgroup when I asked for more tutorials on how to do this is beyond me.

elitism.

Aside from the lack of resources/icons can anyone spot the difference between an X and GTK app ?

gtk (or whatever tookit you're using) draws the border, title and widgets on the window and handles and sends messages through X messages to the parent program where they are either handled or ignored.  to see which messages guilib intercepts, look at the messageLoop procedure in "guilib_frameControl.hla"

the 'X' part you're seeing is just the basic 'frame' which is the part flooded with the background color.

i wanted to get a proof of theory out asap and planned on writing the window control with the button widgets later.  but like i said, i got frustrated trying to find help documents on how to do all that stuff so i just gave up and moved on to greener pastures...windows.

[Sevag.K]

src/class_baselist_node.hla  does not to appear to exist in the hidelib.zip archive and you don't list it in your kmake file.

oops, i just added that recently and haven't uploaded it yet.  this is the src/classlist_node.hla file:

Code Select Expand


unit class_baselist_node_unit;

#includeonce ("hide/hidelib.hhf")
?@nodisplay := true;
?@noalignstack := true;

const
nodeeax :text := "(type tBaseList.baseNode[eax])";


proc

tBaseList.nodes :iterator;
begin nodes;
USE( EAX );
mov( this.head, eax );
while( eax ) do
push( eax );
yield();
pop( eax );
mov( nodeeax.next, eax );
endwhile;
ENDUSE;
end nodes;

end class_baselist_node_unit;


it you want to include it, you'll have to add it to the header file too.  i thought an iterator would be handy since i constantly cycle through all the objects of a list in my programs.

i'll upload the updated library later today when i get a chance.

( Please ignore my logging; it's how I do things :P  )

I tried to emulate your kmake file in a makefile.
Results :

Code Select Expand


$ make hidelib.a
date -u +%F_%T >> log/build.log
hla -c src/env2_envunit.hla >> log/build.log
hla -c src/hide_data.hla >> log/build.log
hla -c src/hide_info.hla >> log/build.log
hla -c src/hide_putmem.hla >> log/build.log
hla -c src/hide_putn.hla >> log/build.log
hla -c src/hide_putz.hla >> log/build.log
hla -c src/hide_stricmp.hla >> log/build.log
hla -c src/mem2_size.hla >> log/build.log
hla -c src/os2_getmodulepath.hla >> log/build.log
Error in file "src/os2_getmodulepath.hla" at line 36 [errid:27596/output.c]:
Parameter type mismatch (zstr).
Near: << , >>


It has a problem with str.cpyz maybe ?

you'll have to account for some changes in the hla stdlib since the library was written.  it's a type casting issue.
change to code to:

str.cpyz( lea( eax, buffer ), dest );

Code Select Expand


HLAPARSE assembly failed with 1 errors
hla -c src/os2_sysexec.hla >> log/build.log
Error in file "src/os2_sysexec.hla" at line 102 [errid:77411/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.tokenize2').
Near: << ( >>


There doesn't appear to be a str.tokenize2 func is this supposed to be tokenize4 or tokenize3 ?

that's a tricky one, but you can probably keep it out of the library since the stdlib has a system command now (but it works a bit differently than mine).

i think you have to use tokenize4 now:

Code Select Expand


tokenize4:
procedure
(
src: string;
delims: cset;
var dest: var;
maxStrs: dword
) {@returns( "eax" )};
@global:_hla._ext( "STR_TOKENIZE4" );

this might work:

str.tokenize4( cmdLn, { ' ', ',' }, cmds, 256 );



?? I was going to ask about the record but I also noticed that you declare a type section inside a class; I thought that was forbidden ??
But you seem to do that in several places but only this one instance gets flagged.
Now that I fixed the commands to not add the hla files to the library this error disappears ??

as of hla 2.15, type sections are allowed in a class as long as you don't try to type a nested class.  it's still fairly new so errors might crop up.  i've had no problems on the windows end.