[Quilltex-main] Weekly Update #4

[Jacob Alexander <haata@us...>]

|||Weekly Update #4|||

||Current Release Target - 0.2 - QuillControl||


|Last Week|

I've been really busy at work, so not too much to update on.

Though I have begun implementing sockets, and they work. They don't really  
do anything yet.

(I want to make Rev 200 a big update, just for the hell of it)

Multi-Monitor
- For Window IDs:

Screen{<screen number>}Inc{<increment>}

ie. Screen{0}Inc{2} for the second window on Screen Zero

If the first window is deleted ( Screen{0}Inc{1} ), then the next window  
created will be Screen{0}Inc{1}

The Increment is not defined by the screen. It is the global increment (so  
for the above ie. there will be no Screen{1}Inc{2})


-For Widget IDs:
(I would like to have part of the ID change based upon the window its in,  
but by design, this is not possible, at least doing it simplistically)

Type[<Widget Type>]Inc[<increment>]CreatedIn[<Window ID created in>]

ie. Type[QuillTerm]Inc[5]CreatedIn[Screen{2}Inc{4}]

So the above would mean: The 5th QuillTerm created, and it just so  
happened to be initialized on the 4th window of Screen 2


|This Week|

Multi-Monitor
- Refine multi-monitor process
- Learn and implement local sockets using Qt

Perhaps:

Widgets
- Create widgets using shared memory rather than locally scoped memory.


We'll see how much I'll actually get done this week.

||Note||

These updates contain info concerning the development of QuillTex on a
weekly basis, that really don't warrant a news post.
Expect, every Monday or Tuesday.


-- 
//
// Jacob Alexander
// QuillTex || Quintessentially
//

Re: [Quilltex-main] Weekly Update #3

[Jacob Alexander <haata@us...>]

|||Weekly Update #3|||

||Current Release Target - 0.2 - QuillControl||


-Late-


|Last Week|

XML Configuration
- All of the current widgets are have XML Config support


Multi-Monitor
- Tried to use Shared Memory in Qt4.4 and Boost to easily solve, across-X,  
multi monitor, wasn't successful, but now I know how to use Shared Memory
(I could use it for everything, except for what I wanted it for...)
- After failing on that, I came up with a new plan for Multi-Monitor


Server/Client Setup using Local Sockets and Shared Memory
1. Client starts
2. Client checks for server
	- If Server is running go to 4.
3. Server is initialized
4. Server assigns client with ID
5. Using this ID the client creates a backlink server
6. Server becomes a client of the backlink server

With this the clients can communicate with each other through the server.
Communication will be through a kind of text "packet" with the form:

TO:<destination ID>|FROM:<source ID>|<data flag>:<data>

I've yet to decide on the ID format, data flag format, and data format.
There will also be special IDs to send to all clients, to the server, and  
groups of IDs.
Additional data flags per packet will also be supported:

TO:<destination ID>|FROM:<source ID>|<data flag>:<data>|<data  
flag2>:<data>|<data flag3>:<data>| etc...

This will solve all communication problems except one. Passing a widget to  
another window.

In order to solve this, ALL, widgets will be created under shared memory,  
and given a special ID. This ID is assigned by the server.

Now, the transfer of a widget goes as such:
1. Widget is put up for adoption by the client.
2. The server recieves the "packet" containing the Widget ID
3. The packet is directed to a client, the server checks for its  
existance, and sends the Widget ID to the client. If the client does not  
exist, nothing happens.
4. The client will add the widget to it's interface on the current focus  
tab for the client.

Now there will be Widget ID list contained in the server, which will be  
constantly updated.
With this list an interface will be available in the form of a tree, in  
which you can move widgets around between clients.

Shared Memory is a requirement to make this work due to how the Widget  
objects are created. Also, making a copy does not work either since the  
copy will not transfer properly between instances of the client.


|This Week|

Multi-Monitor
- Refine multi-monitor process
- Learn and implement local sockets using Qt

Perhaps:

Widgets
- Create widgets using shared memory rather than locally scoped memory.


||Note||

These updates contain info concerning the development of QuillTex on a
weekly basis, that really don't warrant a news post.
Expect, every Monday or Tuesday.


-- 
//
// Jacob Alexander
// QuillTex || Quintessentially
//

[Quilltex-main] Weekly Update #2

[Jacob Alexander <haata@us...>]

|||Weekly Update #2|||


||Current Release Target - 0.2 - QuillControl||


|Last Week|

XML Configuration
- Created QuillXML class to read xml configurations
- QuillTerm is "config-ready"


|This Week|

Quill Control
- Create central configuration dialog
- If possible, use variable type to dynamically generate the config dialog

Widgets
- Prepare all current widgets for configuration options
- Create custom option widgets for configuration dialogs


||Note||

These updates contain info concerning the development of QuillTex on a
weekly basis, that really don't warrant a news post.
Expect, every Monday or Tuesday.

-- 
//
// Jacob Alexander
// QuillTex || Quintessentially
//

Re: [Quilltex-main] RPM Support

[Jacob Alexander <haata@us...>]

The only issue I see would be the versioning.

Which should go:

QuillTex-<major version>.<minor version>.<svn
revision>.<distro>.<architecture>.rpm

So if it was today's svn:

QuillTex-0.1.181.f9.x86_64.rpm


Thanks,

-- 
//
// Jacob Alexander
// QuillTex || Quintessentially
//

[Quilltex-main] RPM Support

[Scott Stobbe <scott.j.stobbe@gm...>]

I would be interested maintaining an RPM package of QuillTex, likely not
for another few week though.

However before that can happen, I think QuillTex needs a release scheme
implemented more thoroughly and documented in some form. Unless you
would like SRC RPMS to literally fetch the active source... 

Things to consider, naming conventions, package descriptions, ... etc.

Scott Stobbe

[Quilltex-main] Weekly Update #1

[Jacob Alexander <haata@us...>]

|||Weekly Update #1|||


||Current Release Target - 0.2 - QuillControl||


|Last Week|

QuillSwallow
- Started and Finished (for this release anyways, unless there are blatant  
bugs)
- Allows for users to embed or "swallow" up other X11 applications
- Allows for users to embed or "throw" applications such as mplayer(works  
great!) or xterm (bad example as it doesn't work that well with focus)

Tabbing
- Quick Tabs work!!
(Well they've been working since at least since July 1st for the most part  
I just forgot to add the menu options)
- The controller at the bottom is a separate entity and is still really  
buggy

Multi Monitor (actually two weekends ago)
- Very basic implementation
(Use at your own risk)
- Window switching works if you don't close windows


|Next Week|

Tabbing
- Fix the buggy mess at the bottom
- Implement custom tab titles and an interface to create and switch  
between them

WOR (Whimsical OR)

XML Configuration
- Implement a framework for XML configurations for each widget


||Note||

These updates contain info concerning the development of QuillTex on a  
weekly basis, that really don't warrant a news post.
Expect, every Monday or Tuesday.

-- 
//
// Jacob Alexander
// QuillTex || Quintessentially
//

[Quilltex-main] Test Post

[Jacob <haata@us...>]

See if this thing works.

-Jacob