Page 47 of 54

Re: Mudlet features and API requests

Posted: Sat Apr 25, 2015 8:46 pm
by Vadi
Use <br> in a label.

Re: Mudlet features and API requests

Posted: Sun Apr 26, 2015 4:34 pm
by azure_glass
How to do it? Example please :)

Re: Mudlet features and API requests

Posted: Sun Apr 26, 2015 8:07 pm
by Vadi
testlabel:echo("one line<br>another line")

Re: Mudlet features and API requests

Posted: Wed Jul 29, 2015 8:37 pm
by tarkenton
Haven't gone digging, as this was a toilet thought. Is there any way to put the notes functionality into a label/miniconsole? If not, that's something I and others would find handy since it would allow for a scratchpad to easily be implemented to store info people want to scribble down or see at a glance that is really changeable.

Re: Mudlet features and API requests

Posted: Wed Jul 29, 2015 9:41 pm
by SlySven
<aside>I hope you made sure you wash your hands after...!</aside> The data is stored in the "notes.txt" file in the root of the profile's directory tree so you could always read and write it via lua file handling code stuff - though it is stored as a UTF-8 file. A quick check did reveal that the reader code {in the C++ method dlgNotepad::restore()} did not close the QFile that it creates to read in the contents - and the code that writes out the data when you close the "notes" window will overwrite the existing file; so if you are going to fiddle with the file yourself you want to tell the user when it is safe for them to have the "notes" window open (NOT while you are changing the file).

Mind you, the notes functionality is already there "to store info people want to scribble down or see at a glance that is really changeable" - just not one that can be customised to fit into a scripted/customisable part of a GUI - or is that what you want?

Re: Mudlet features and API requests

Posted: Thu Jul 30, 2015 2:12 am
by tarkenton
Fitting into a GUI is exactly what I'm looking for. Figured why recode if the functionality is already there. Is no big deal, I can write a simple, terribly optimized scratch pad. But having the user able to click on a GUI window, and just write something, would be nice instead of aliases and the like.

Re: Mudlet features and API requests

Posted: Thu Aug 06, 2015 3:57 pm
by EulersIdentity
[ ALERT ] - Socket got disconnected.
English grammar dictates that this should be "Socket was disconnected."

On a more serious note I would love an option in the settings menu to set the location of the profiles directory. I know that things like the symlink workaround exist, but this seems like overkill if its possible to just have Mudlet look for files in a different location. I travel a lot right now and it would be really awesome if all I had to do to use Mudlet were to pop in a flash drive and open the executable.

Re: Mudlet features and API requests

Posted: Thu Aug 06, 2015 4:14 pm
by SlySven
I did a quick check in the source and found the equivalent of QDir::homeDir() + "/.config/mudlet/profiles/" is used in lots {where lots is significantly more than ten} of places! From a coding point of view I agree that perhaps the "profiles" directory might usefully be a variable - though extending this to further up the directory structure for ALL of Mudlet's stuff could give us a chicken and egg situation where the location that stores the data would be stored in a file (the Mudlet main "QSetting" file mudlet.ini) which needs to be readable to FIND the location before you can read from it...! :P

Re: Mudlet features and API requests

Posted: Thu Aug 06, 2015 4:44 pm
by EulersIdentity
I'm speaking from a position of ignorance, so sorry if this is nonsense, but wouldn't it be best to put the location of the settings files as early as possible in the hierarchy? Any time I've coded something that relies on a configuration file to determine its behavior, I've put that file in the same directory (or sub-directory) as the executable and then had the program read settings from the file as early as I could. I also haven't written anything terribly large, so I may be misunderstanding the problem.

Re: Mudlet features and API requests

Posted: Sun Aug 09, 2015 4:07 am
by SlySven
That doesn't always apply for OS specific file configuration locations - and it also depends on whether the settings are for a particular user or for the application's use independent of who is currently running it {of course if more than one person is using it on the same system simultaneously that also makes some things more complex} :wink:

As it happens we currently assume that the Mudlet application is configured for each user independently of any other - so the use of a sub-directory of the almost hidden ~/.config/ directory is the right thing for *nix environments, but I'm not quite so clear on how things are for other platforms...