Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(30) |
Dec
(10) |
| 2018 |
Jan
(44) |
Feb
(44) |
Mar
(32) |
Apr
(49) |
May
(45) |
Jun
(7) |
Jul
(15) |
Aug
(84) |
Sep
(95) |
Oct
(36) |
Nov
(88) |
Dec
(41) |
| 2019 |
Jan
(21) |
Feb
(27) |
Mar
(67) |
Apr
(25) |
May
(69) |
Jun
(45) |
Jul
(65) |
Aug
(15) |
Sep
(20) |
Oct
(42) |
Nov
(109) |
Dec
(62) |
| 2020 |
Jan
(58) |
Feb
(36) |
Mar
(84) |
Apr
(169) |
May
(325) |
Jun
(267) |
Jul
(43) |
Aug
(3) |
Sep
(27) |
Oct
(25) |
Nov
(25) |
Dec
(7) |
| 2021 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(55) |
May
(24) |
Jun
(36) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(98) |
Mar
(15) |
Apr
(31) |
May
(4) |
Jun
(23) |
Jul
(45) |
Aug
(15) |
Sep
(75) |
Oct
(8) |
Nov
(10) |
Dec
(12) |
| 2023 |
Jan
(5) |
Feb
(49) |
Mar
(31) |
Apr
(3) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(161) |
Sep
(8) |
Oct
(7) |
Nov
(27) |
Dec
(26) |
| 2024 |
Jan
(24) |
Feb
(35) |
Mar
(11) |
Apr
(38) |
May
(13) |
Jun
(39) |
Jul
(2) |
Aug
(24) |
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(18) |
| 2025 |
Jan
(82) |
Feb
(11) |
Mar
(9) |
Apr
(13) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Miro K. <mir...@gm...> - 2018-01-28 05:32:53
|
That's exactly why it's on github: fork -> edit -> pull request. 100% web gui operations. On 28 January 2018 at 16:30, Paul Wratt <pau...@gm...> wrote: > needs updateing > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Paul W. <pau...@gm...> - 2018-01-28 05:30:50
|
needs updateing |
|
From: Mark D. <mdu...@at...> - 2018-01-27 14:46:58
|
I'm really glad there is so much positive feedback. I really thought people must still be using easymint based systems. I do not intend to provide any tools for updating kernel or xaaes. This is a problem that is common and identical to all mint users whether they are running an ext2 partition with unix software or not. Plus there are so many different potential ways people want to do this that I would rather not speak to "how" it should be done. Sparemint/easymint historically will run the same whether you are running an older or a newer kernel. So it doesn't make a meaningful difference to me. If your unix dir symlinks are populated right, that is all rpmint really needs. (/usr, /var, /etc). Indeed this distro will not provide a mint kernel package at all. The booting and boot scripts will handle the unix software portion only (and can run xaaes or login prompt at the end). Existing users will be able to install rpmint on top of an existing sparemint/easymint system, or the author of easymint will be able to create a new easymint distribution based on rpmint. Or if time passes and I am really productive, I will look into the problem. I think my goals as they sit now are lofty for the time I generally have available. I think the need is there for a system boot management application. It would show a list of available uniformly built mint kernel/xaaes/driver packages on the internet (by the ci server for instance) for download and which ones are installed. When you choose a different one it would provision the mint folder, copy the auto prg and make whatever other changes are required for that config. It would also copy any custom xfs/xif and in general tailor the new kernel install to your specific tastes (cfg's, etc). A very modest scripting language just to set everything up. GEM assist may already be a good candidate for this. To me this should be a GEM only app and to me this is complimentary to the work I'm doing but not part of it. Thanks, Mark On 01/27/2018 02:21 AM, Jean-François Lemaire wrote: > Speaking of this project, I think it's a great idea and I hope it will reach > completion. One query I have is how do you plan on interfacing the RPM distro > with the FreeMiNT kernel/AES? EasyMint made things overly complex in that > respect and I would hate to have to edit scripts and/or config files just > because I'm booting another kernel. > > Cheers, > JFL > |
|
From: Jean-François L. <jfl...@sk...> - 2018-01-27 07:21:44
|
On Friday, 26 January 2018 22:52:37 CET Mark Duckworth wrote: > I actually already created an updater for sparemint called sum. I think > this was in C and Windom. I think that would be a valid basis for > future tools though it's a very simple interface. I'll check out > GEMassist but my worries are the network communications and working with > the package database, though this could all just be done with other cli > tools. I remember using SUM a couple of times back in the day and it worked. Here's an announcement you made to refresh your memory ;-) https://mikro.naprvyraz.sk/mint/200508/msg00044.html Speaking of this project, I think it's a great idea and I hope it will reach completion. One query I have is how do you plan on interfacing the RPM distro with the FreeMiNT kernel/AES? EasyMint made things overly complex in that respect and I would hate to have to edit scripts and/or config files just because I'm booting another kernel. Cheers, JFL -- Jean-François Lemaire |
|
From: Paul W. <pau...@gm...> - 2018-01-27 01:33:38
|
This sounds great, and nice to see previous work has not gone to waste Having spec's and patches on github would be a bonus too, and for your project (server) you could keep a local repo so updates are not bulk downloads, but you can also pull raw files too I would ask to find a location on the net to provide alternate/backup for finalized SRPM/RPM, a location that is going to be around for years to come, in case for some reason you net/server/app is not available in the future. This also supports installs not having to do a dist-upgrade just to get a usable SRPM/RPM for that install. And it would support distro mirror in the southern hemisphere (and/or european mirrors) (mostly for speed) To that end, github allows binary package releases (placed on a seperate repo obviously), and sourceforge has php and "project web space". There is no reason why both GH & SF could not be employed to support redundancy and assist web frontends. I support adding cross-build at a later date, at least to the point where your app is working 100% for native builds, at least then someone else can work on the cross-build as well (if need be) To help support native builds and possibly improve speed and resource use, I have asked on the ARAnyM list re:CLI (non-gui) version of ARAnyM. I hope that will produce some results too, as it has the potential to affect gui versions for possible (input) scripting later on With this project, someone else would be able to supply a "distro image" as well, which would be useful for Native AtariST, not just ARAnyM (esp. on RPi) Cheers, looking forward to the results Paul On 1/26/18, Mark Duckworth <mdu...@at...> wrote: > In principle I agree with this but in practice I wonder how it would > work with RPM's opinionated ways. To generate an SRPM file which is the > theoretical input to such a project, RPM basically demands the source > files, patches, and a spec file and the whole thing has to build > successfully. If it does, it will create the SRPM along with the final > package. The utility there, at least for me, is that if you manage to > get an SRPM file you've probably assembled it all properly. Someone > would upload an SRPM file which contains everything and the autobuilder > would take it from there. No doubt we will have libraries that will > break other packages taht depend on it, so we'll have to have some trial > mechanism that demands a successful build of dependent packages before > the new one replaces anything. > > It wouldn't be the end of the world to forgo that and instead trust the > specs that people upload are well tested. And lets be realistic here, > there will be very few people actually contributing. The problem there > is that there would be a ton of binary content on github. You know the > .tar.gz source files for packages. Not a well advised idea and a git > pull would slowly get insanely huge. I think this is what is going on > with cocoapods which can take a long time to sync. > > Alternatively, you could store only patches and specs github and source > code on rpmint ftp. The spec could reference the source url on the > rpmint server (I would insist on having a local copy as we tend to get > far behind other systems in versions). This isn't an awful idea as in > theory the source archive should be the same (and should validate with > md5 or sha1 sum). It looks like there are tools that will download > source from an input spec file. > > https://stackoverflow.com/questions/33177450/how-do-i-get-rpmbuild-to-download-all-of-the-sources-for-a-particular-spec > > So I can use github to the extent that patches and specs are stored > there. The question is, is the purpose of the autobuilder to vet > people's raw source changes (autobuild on hook from spec/patch commit), > or is the purpose to submit a well vetted prebuilt SRPM and get back out > optimized versions for coldfire, 68020 and 68000. I think the latter is > for me. > > > On 01/25/2018 05:13 PM, Miro Kropáček wrote: >> >> > >> What I would recommend here is to open a github repository which would >> contain package sources and setup git hooks to your server -- that way >> it's super easy to contribute/fix packages and you can focus solely on >> the building part & GUI for downloading/searching etc. In fact, this >> (the need to have an own server if you want to track build dependencies) >> is the only reason why we already don't have this in FreeMiNT (so you >> can't push a change to, say, gemlib and get freemint's tools rebuilt). > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Peter S. <p....@sc...> - 2018-01-26 20:59:34
|
I had originally intended to use my GEMasist to create a quick rpm installer and updater. Peter On Fri, 26 Jan 2018 02:24:45 , Thorsten Otto <ad...@th...> wrote: > This is a multi-part message in MIME format. > On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote: > I bought rpmint.com and wanted to announce that I wanted to > fork/continue on with sparemint as a new name, RPMint. That sounds great. > GEM/CLI package installer/updater cli shouldn't be that difficult, but gem would be very ambitioned. >Build farm is an M5484LITE board for coldfire, and two aranym instances >for 68000 and 68020-60. Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to cross- compile such packages on a linux box. I'm not sure ether you are aware of it, but i already updated some packages and made them available on http://tho-otto.de/crossmint.php This are just tar archives however, not RPMs |
|
From: Mark D. <mdu...@at...> - 2018-01-26 16:10:22
|
I'm going to target building on native hardware for now. I've had a lot of fun adapting packages to cross building and I know some of them just don't take well to it at all. Obviously I know for the most part this stuff is solved with things like bitbake so I know it's all possible. If someone wants to take my work and add cross building, I will support it and work with it but for now my main interest is building under aranym (as it's extremely fast for me on my xeon servers). Thanks, Mark On 01/26/2018 09:34 AM, Thorsten Otto wrote: > On Freitag, 26. Januar 2018 03:27:43 CET Mark Duckworth wrote: >> RPM does not really support cross compiling in any meaningful way. At >> least not the older version we are using. > I'm not sure which rpm version you intend to use, but in most cases it is just > a matter of choosing a different compiler, and adding the corresponding flags > to the configure arguments. Both can be done in the spec file, so i don't see > a reason why this shouldn't be supported. > > For example, attached is a spec file for bzip2. It needs the same patches i > used in my custom build scripts (http://tho-otto.de/download/mint/bzip2-1.0.6-mint.tar.xz) |
|
From: Thorsten O. <ad...@th...> - 2018-01-26 14:34:10
|
On Freitag, 26. Januar 2018 03:27:43 CET Mark Duckworth wrote: > RPM does not really support cross compiling in any meaningful way. At > least not the older version we are using. I'm not sure which rpm version you intend to use, but in most cases it is just a matter of choosing a different compiler, and adding the corresponding flags to the configure arguments. Both can be done in the spec file, so i don't see a reason why this shouldn't be supported. For example, attached is a spec file for bzip2. It needs the same patches i used in my custom build scripts (http://tho-otto.de/download/mint/bzip2-1.0.6-mint.tar.xz) |
|
From: Mark D. <mdu...@at...> - 2018-01-26 02:27:58
|
RPM does not really support cross compiling in any meaningful way. At least not the older version we are using. Thanks, Mark On 01/25/2018 08:24 PM, Thorsten Otto wrote: > On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote: > >> I bought rpmint.com and wanted to announce that I wanted to > >> fork/continue on with sparemint as a new name, RPMint. > > > > That sounds great. > > > >> GEM/CLI package installer/updater > > > > cli shouldn't be that difficult, but gem would be very ambitioned. > > > >>Build farm is an M5484LITE board for coldfire, and two aranym instances > >>for 68000 and 68020-60. > > > > Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to > cross-compile such packages on a linux box. > > > > I'm not sure ether you are aware of it, but i already updated some > packages and made them available on http://tho-otto.de/crossmint.php > This are just tar archives however, not RPMs > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Thorsten O. <ad...@th...> - 2018-01-26 01:24:54
|
On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote: > I bought rpmint.com and wanted to announce that I wanted to > fork/continue on with sparemint as a new name, RPMint. That sounds great. > GEM/CLI package installer/updater cli shouldn't be that difficult, but gem would be very ambitioned. >Build farm is an M5484LITE board for coldfire, and two aranym instances >for 68000 and 68020-60. Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to cross- compile such packages on a linux box. I'm not sure ether you are aware of it, but i already updated some packages and made them available on http://tho-otto.de/crossmint.php This are just tar archives however, not RPMs |
|
From: Vincent R. <vin...@fr...> - 2018-01-25 23:59:25
|
On 25/01/2018 at 18:55, Mark Duckworth wrote: > I bought rpmint.com and wanted to announce that I wanted to fork/continue > on with sparemint as a new name, RPMint. Nice project! Go ahead. -- Vincent Rivière |
|
From: Mark D. <mdu...@at...> - 2018-01-25 22:51:03
|
In principle I agree with this but in practice I wonder how it would work with RPM's opinionated ways. To generate an SRPM file which is the theoretical input to such a project, RPM basically demands the source files, patches, and a spec file and the whole thing has to build successfully. If it does, it will create the SRPM along with the final package. The utility there, at least for me, is that if you manage to get an SRPM file you've probably assembled it all properly. Someone would upload an SRPM file which contains everything and the autobuilder would take it from there. No doubt we will have libraries that will break other packages taht depend on it, so we'll have to have some trial mechanism that demands a successful build of dependent packages before the new one replaces anything. It wouldn't be the end of the world to forgo that and instead trust the specs that people upload are well tested. And lets be realistic here, there will be very few people actually contributing. The problem there is that there would be a ton of binary content on github. You know the .tar.gz source files for packages. Not a well advised idea and a git pull would slowly get insanely huge. I think this is what is going on with cocoapods which can take a long time to sync. Alternatively, you could store only patches and specs github and source code on rpmint ftp. The spec could reference the source url on the rpmint server (I would insist on having a local copy as we tend to get far behind other systems in versions). This isn't an awful idea as in theory the source archive should be the same (and should validate with md5 or sha1 sum). It looks like there are tools that will download source from an input spec file. https://stackoverflow.com/questions/33177450/how-do-i-get-rpmbuild-to-download-all-of-the-sources-for-a-particular-spec So I can use github to the extent that patches and specs are stored there. The question is, is the purpose of the autobuilder to vet people's raw source changes (autobuild on hook from spec/patch commit), or is the purpose to submit a well vetted prebuilt SRPM and get back out optimized versions for coldfire, 68020 and 68000. I think the latter is for me. On 01/25/2018 05:13 PM, Miro Kropáček wrote: > > > What I would recommend here is to open a github repository which would > contain package sources and setup git hooks to your server -- that way > it's super easy to contribute/fix packages and you can focus solely on > the building part & GUI for downloading/searching etc. In fact, this > (the need to have an own server if you want to track build dependencies) > is the only reason why we already don't have this in FreeMiNT (so you > can't push a change to, say, gemlib and get freemint's tools rebuilt). |
|
From: Miro K. <mir...@gm...> - 2018-01-25 22:13:42
|
On 26 January 2018 at 04:55, Mark Duckworth <mdu...@at...> wrote: * Auto builder which builds same packages for coldfire, 68020-60 and 68000 > Sounds great, Mark! > * Clean up rpm build dependencies so that autobuild can rebuild > everything from scratch without screwing up the dependencies. The > purpose being that if a static lib is updated, the entire system can be > updated automatically. Backend will facilitate this and will bump up > revisions prompting package updates. > [..] * Comprehensive website (will be postgresql/c#/mvc running on > mono/linux). Will allow package upload, community approval, deployment > to auto build servers, searching by file, package info, historical > package archive, etc. The autobuilder will also be a C# app that will > monitor and control via ssh. > What I would recommend here is to open a github repository which would contain package sources and setup git hooks to your server -- that way it's super easy to contribute/fix packages and you can focus solely on the building part & GUI for downloading/searching etc. In fact, this (the need to have an own server if you want to track build dependencies) is the only reason why we already don't have this in FreeMiNT (so you can't push a change to, say, gemlib and get freemint's tools rebuilt). -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2018-01-25 17:55:52
|
Hello all, I bought rpmint.com and wanted to announce that I wanted to fork/continue on with sparemint as a new name, RPMint. What I am planning to do is a slight divergence from sparemint but ultimately the same. The goals are: * Auto builder which builds same packages for coldfire, 68020-60 and 68000 * Clean up rpm build dependencies so that autobuild can rebuild everything from scratch without screwing up the dependencies. The purpose being that if a static lib is updated, the entire system can be updated automatically. Backend will facilitate this and will bump up revisions prompting package updates. * Revised init scripts which run a bit faster and leaner - up for debate * Updated packages (many already completed just need to put it all together) * GEM/CLI package installer/updater * Comprehensive website (will be postgresql/c#/mvc running on mono/linux). Will allow package upload, community approval, deployment to auto build servers, searching by file, package info, historical package archive, etc. The autobuilder will also be a C# app that will monitor and control via ssh. * For experienced users or for others to build on... Primary focus on unix cli tools and ports - easymint and other products should take RPMint work and build on it. RPMint is JUST the distro, not an installer or kernel maintenance tools. Kernel will not be a package at all. RPMint is just intended to maintain what is on the ext2 partition traditionally so no xaaes, no kernel, etc. * RPMint will lift and otherwise reuse community work whenever possible. Vincent Riviere's patches, Alan's work with gentoo, etc. I did work on all this before but I lost interest due to a lack of control over sparemint and no interest from sparemint people. Now I have no excuses so we'll see what I can do with it. It's vaporware at the moment but I wanted to put this out there to allow people to comment and offer opinions on how things should go. Ultimately I do not plan to exercise a lot of control over this but just wanted a platform with which to share the ports I've done.. and I prefer RPM. Build farm is an M5484LITE board for coldfire, and two aranym instances for 68000 and 68020-60. Ssh access provided to anyone who wants to work on it, maintain or participate... Or even build their own software. 68000 is no longer really a waste of time due to MonSTer board and MiST if anyone ever figures out the block io issues on that. Thanks, Mark |
|
From: Arnaud B. <arn...@gm...> - 2018-01-24 06:24:32
|
Hello, The windom library supports that kind of feature, but it's not applicable for QED (because QED is not built over windom). http://windom.sourceforge.net/doc/html/group__Frame.html Arnaud. Le mer. 24 janv. 2018 à 01:48, Paul Wratt <pau...@gm...> a écrit : > I suggest you build a demo > > essentually you are describing a window with 2x border-less windows > containded within > > This might sound useful, but for it to be totally usable across > various projects (ie different use cases) it would need a fair few > option for creation, with a default configuration of 100% height 50% > split for common use > > Is there not already a library with this functionality > > Just an thought > > Paul > > On 1/22/18, Peter Slegg <p....@sc...> wrote: > > > > I was considering making a feature request for QED but I am not sure > > if it could be done in AES. > > > > Would it be possible to have a split window feature ? I don't think > > I've ever seen this in a GEM app. > > > > Divide the window horizontally with two sets of vertical scroll bars > > or divide it vertically with two sets of horizontal scroll bars. > > > > I suppose this would be a bit like frames in a browser. > > > > Another sugestion would be the ability to collapse/expand blocks of > > code. So every line between braces {} could be hidden and a small icon > > is used to expand it again. I think that may be harder to implement. > > > > > > > > Cheers, > > > > Peter > > > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Freemint-discuss mailing list > > Fre...@li... > > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: WongCK <won...@ya...> - 2018-01-24 05:07:59
|
On Wednesday, 24 January 2018, 10:34:57 AM GMT+8, Paul Wratt <pau...@gm...> wrote: >Umm.. there is always the "AtariST" way of doing things too, at least under mint
well, yes of course... i don't do that even as I know it
I actually use Teradesk viewer to view the "other section" of the source code.Only thing lacking there is I cannot do a copy.
plenty of ways to skin a cat/banana |
|
From: Miro K. <mir...@gm...> - 2018-01-24 03:00:25
|
> > However if it were to be developed in QED, it would demand a fork, and > is that still possible with atariforge being done (mostly?) > Huh? Qed is on github for some time: https://github.com/freemint/qed -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Paul W. <pau...@gm...> - 2018-01-24 02:34:54
|
Umm.. there is always the "AtariST" way of doing things too, at least under mint open 2x QED align windows 50/50 save only with one window, other should notify of change from memory (or am I thinking maybe LeafPad on Linux ?) However if it were to be developed in QED, it would demand a fork, and is that still possible with atariforge being done (mostly?) Paul On 1/24/18, WongCK via Freemint-discuss <fre...@li...> wrote: > > > On Sunday, 21 January 2018, 7:12:33 PM GMT+8, Peter Slegg > <p....@sc...> wrote: > Would it be possible to have a split > window feature ? I don't think >>I've ever seen this in a GEM app. > > May be windom demo has it?IIRC, I saw a window with 2 parts that you can > scroll.... but I think it is not exactly a split. > > |
|
From: WongCK <won...@ya...> - 2018-01-24 01:57:05
|
On Sunday, 21 January 2018, 7:12:33 PM GMT+8, Peter Slegg <p....@sc...> wrote: > Would it be possible to have a split window feature ? I don't think
>I've ever seen this in a GEM app.
May be windom demo has it?IIRC, I saw a window with 2 parts that you can scroll.... but I think it is not exactly a split.
|
|
From: WongCK <won...@ya...> - 2018-01-24 01:51:37
|
QED currently does not allow to open 2 windows of the same file. ( or am I just not aware of how).if it is allowed, wouldn't it be simpler than to have a split in the work area of the window ?The contents of the 2 windows will have to sync with each other if one changes (should be simple to achieve).Then it just a matter of arranging the 2 windows -> left-right, top-bottom... etc. (auto arrange windows should also be simple to do)
These features I also found it lacking in QED as I find myself scrolling up and down to see functions etc while programming.
Just my 2 cents. On Wednesday, 24 January 2018, 8:48:51 AM GMT+8, Paul Wratt <pau...@gm...> wrote:
I suggest you build a demo
essentually you are describing a window with 2x border-less windows
containded within
This might sound useful, but for it to be totally usable across
various projects (ie different use cases) it would need a fair few
option for creation, with a default configuration of 100% height 50%
split for common use
Is there not already a library with this functionality
Just an thought
Paul
On 1/22/18, Peter Slegg <p....@sc...> wrote:
>
> I was considering making a feature request for QED but I am not sure
> if it could be done in AES.
>
> Would it be possible to have a split window feature ? I don't think
> I've ever seen this in a GEM app.
>
> Divide the window horizontally with two sets of vertical scroll bars
> or divide it vertically with two sets of horizontal scroll bars.
>
> I suppose this would be a bit like frames in a browser.
>
> Another sugestion would be the ability to collapse/expand blocks of
> code. So every line between braces {} could be hidden and a small icon
> is used to expand it again. I think that may be harder to implement.
>
>
>
> Cheers,
>
> Peter
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Paul W. <pau...@gm...> - 2018-01-24 00:48:49
|
I suggest you build a demo
essentually you are describing a window with 2x border-less windows
containded within
This might sound useful, but for it to be totally usable across
various projects (ie different use cases) it would need a fair few
option for creation, with a default configuration of 100% height 50%
split for common use
Is there not already a library with this functionality
Just an thought
Paul
On 1/22/18, Peter Slegg <p....@sc...> wrote:
>
> I was considering making a feature request for QED but I am not sure
> if it could be done in AES.
>
> Would it be possible to have a split window feature ? I don't think
> I've ever seen this in a GEM app.
>
> Divide the window horizontally with two sets of vertical scroll bars
> or divide it vertically with two sets of horizontal scroll bars.
>
> I suppose this would be a bit like frames in a browser.
>
> Another sugestion would be the ability to collapse/expand blocks of
> code. So every line between braces {} could be hidden and a small icon
> is used to expand it again. I think that may be harder to implement.
>
>
>
> Cheers,
>
> Peter
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
|
|
From: Peter S. <p....@sc...> - 2018-01-21 11:12:29
|
I was considering making a feature request for QED but I am not sure
if it could be done in AES.
Would it be possible to have a split window feature ? I don't think
I've ever seen this in a GEM app.
Divide the window horizontally with two sets of vertical scroll bars
or divide it vertically with two sets of horizontal scroll bars.
I suppose this would be a bit like frames in a browser.
Another sugestion would be the ability to collapse/expand blocks of
code. So every line between braces {} could be hidden and a small icon
is used to expand it again. I think that may be harder to implement.
Cheers,
Peter
|
|
From: Roger B. <an...@xp...> - 2018-01-12 20:22:26
|
On 12 Jan 2018 at 19:16, Peter Slegg wrote: > On Thu, 11 Jan 2018 12:03:35 , WongCK via Freemint-discuss > <fre...@li...> wrote: > > Is there any way to set my sourceforge mailing options so that: > > 1. I get a digest message once each day > 2. The messages are in plain email text and not attachments. > I think the answer is no, the format of the digest is not specifiable. As a matter of interest, if the answer were yes, what would a digest message actually look like? A bunch of messages concatenated together with all the header info included? That would, I think, be less useful. Roger |
|
From: Peter S. <p....@sc...> - 2018-01-12 19:17:01
|
On Thu, 11 Jan 2018 12:03:35 , WongCK via Freemint-discuss <fre...@li...> wrote: Is there any way to set my sourceforge mailing options so that: 1. I get a digest message once each day 2. The messages are in plain email text and not attachments. Cheers, Peter |
|
From: WongCK <won...@ya...> - 2018-01-11 12:03:50
|
Ah So.... VT52 escape code. Thanks for the hint.
On Thursday, 11 January 2018, 3:44:45 PM GMT+8, Helmut Karlowski via Freemint-discuss <fre...@li...> wrote:
,---------------------------------------------------
> When developing software, my debug output comes out to the TOSWIN console window.As I need a clean output most of the time, I clear the window by closing and opening it.Can there be a menu item or shortcut combo to clear the console window?Thanks.
> rgdswongck
I use:
alias clsc='print -n \\033E >/dev/console'
Your shell might need a different syntax for EscE.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
5 messages has been excluded from this view by a project administrator.
