[M3devel] cm3 does not support Scan.LongInt

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Sat Dec 14 21:31:58 CET 2013


Hi all,
not me, but somebody was happily (well almost) compiling 200k lines of Modula-3 from Qt headers some months ago.
But I don't know how to browse in that page, I'm openly against new UI in web pages :), are just too crazy, maybe I'm just too old for that technology. Can you help to contact demoitem guy:
https://github.com/swig/swig/pull/84

Thanks in advance





El Sábado 14 de diciembre de 2013 5:45, Elmar Stellnberger <estellnb at elstel.org> escribió:
 
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/08720125/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/08720125/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/08720125/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/08720125/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/08720125/attachment-0005.jpe>


More information about the M3devel mailing list