[M3devel] cm3 does not support Scan.LongInt

Sat Dec 14 11:45:18 CET 2013

Converting my automaton simulator I have just discovered that there is 
no Scan.LongInt though there is a Fmt.LongInt.
Would anyone mind this to fix in the main trunk?

Also I hope that there will be a ready-to-use GUI as soon as I will come 
into implementing the GUI part of the simulator.
I had a superfluous look at Modula-3 Qt but I am not yet sure on how the 
signal concept was mapped onto Modula-3.
How do I f.i. listen to a 'pressed' signal on a QPushButton?
There is no 'pressed' method or procedure variable in the 
QAbstractButton interface which I could override.
Daniel, could you have a look at it? At worst the Qt port could be 
infunctional (Sorry, I haven`t tried that yet.).
Also I believe a full integration of Randys Trestle port could give us 
an additional backup if something did not work with the Qt port.

and: Concerning the widechar support, 16bit characters will just be fine 
for Qt as it does internally use UTF-16 and thus UTF-16 character arrays 
can be directly converted into a QString. So if we would choose to 
introduce a 32bit character type I would give it another name like f.i. 
UCHAR in order not to break code that does rely on the current 16bit 
character width.

Elmar

Am 04.12.13 18:52, schrieb Jay K:
> Randy, definitely at least some of your changes got in.
> For example, see:
> https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/
> The changes involved forking large files to make small changes, and 
> apparent bugs resulted as the files drifted apart.
>
>
> There are Qt bindings in the tree now.
> I haven't tried them yet.
> Qt is probably the way to go.
>
>
> The challenge in all this is coming up with the right abstraction or 
> adopting the correct existing abstraction.
> In the language we have a "record". This turns out to be very portable.
> All processors and intermediate representations support it, or will be 
> force of existing practise throughout the software industry (i.e. C 
> has structs, therefore structs and anything resembling them shall 
> always work efficiently).
>
>
> Then, what is the right abstraction for a GUI library?
> What will always be "easy enough" to implement on hardware or on top 
> of other libraries?
> And, how far down do we implement and meet the next layer?
> Is the next layer a video buffer? Or a high level library? Or 
> generating html for "complete reinterpretation"?
> A thin stateless wrapper where someone else does 99.9% of the work?
>
>
> And then implementing our part of it.
>
>
>  - Jay
>
> ------------------------------------------------------------------------
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 4 Dec 2013 03:10:03 +0000
> Subject: Re: [M3devel] VBT and up to date desktop styling
>
> Elmar:
>
> Years ago, I worked with the principals at Critical Mass to make some 
> Trestle/VBT/VBTKit changes that would make the “look and feel” more 
> Windows-like.
>
> I'm pretty sure I passed all these to Olaf for incorporation into the 
> CVS repository.
>
> I developed some GUIs that looked decent at the time on Windows NT, 
> but more work could be done to provide tighter integration.
>
> Not sure if these pics will come thru in the email, but I've pasted a 
> few below to give you some idea of what we achieved using Trestle, 
> VBTKit, FormsVBT, etc.
>
> Of course, at that time, our primary motivation was to have one set of 
> GUI code that worked on multiple platforms and gave same look and 
> feel, so tight integration with the underlying OS was not the driving 
> concern.  Our code ran well and provided same look and feel on both 
> HP-UX and Windows.
>
> Thanks,
>
> Randy Coleburn
>
> -----Original Message-----
> From: Elmar Stellnberger [mailto:estellnb at elstel.org]
> Sent: Sunday, December 01, 2013 2:26 PM
> To: m3devel
> Subject: EXT:[M3devel] VBT and up to date desktop styling
>
> As the VBT standard interface does only offer black and white user 
> interface styling I would need to use vbtkit to achieve at least a 
> Windows 3.1 similar user interface. However as I have found out some 
> of the classes in vbtkit required just for the main menu have not been 
> completed and do not compile yet. Would someone be ready to invest 
> some time and affection to complete these classes?
>
> To make MainMenu.m3 look good at least the following tasks would have 
> to be done:
>
> * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of 
> the popup menus in the main menu
>
> * ShadowedBarVBT: is here but does not seem to work: it should display 
> a horizontal bar in one of the popup menus
>
> * ShadowVBT: to be completed: draw a 3D border around popup menus and 
> other items
>
> * Shadow: have a third color besides background and foreground for the 
> flat style: eliminate the white borders in non-hover mode
>
> * adjust the vbtkit menu so that the popup menus stays open if the 
> mouse button is released; this will also be necessary to make 
> sub-menus of popup-menus work; i.e. let popup menus contain 
> AnchorSwitchVBTs
>
> * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs 
> shadows appear to be larger in their horizontal extent by now compared 
> to their vertical extent which is not that good to look at
>
> * and likely some other issues I have not discovered yet
>
> Considering all of that if I will not have an extended vbtkit 
> interfacing with another GUI component like GTK would likely be the 
> way to go because otherwise there would simply be too much time to be 
> invested into vbtkit not considering underlying Trestle problems like 
> Unicode support yet. Though it would be good to have a well working 
> standard GUI interface for Modula-3 we need to consider now if putting 
> further work into Trestle/vbtkit is still worth to do. If so I believe 
> it would require a joint effort.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131214/8f152255/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 57950 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131214/8f152255/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 47526 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131214/8f152255/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 51415 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131214/8f152255/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 106584 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131214/8f152255/attachment-0005.jpe>